From mjw@redhat.com  Mon Jun  2 12:07:14 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Mon, 02 Jun 2014 14:07:14 +0200
Subject: [Dwarf-Discuss] Proposal to add DW_AT_alignment
In-Reply-To: <20140528233353.GQ4265@adacore.com>
References: <1400160549.4005.40.camel@bordewijk.wildebeest.org>
	<1401287172.4106.110.camel@bordewijk.wildebeest.org>
	<20140528233353.GQ4265@adacore.com>
Message-ID: <1401710834.4030.53.camel@bordewijk.wildebeest.org>

On Wed, 2014-05-28 at 16:33 -0700, Joel Brobecker wrote:
> Very interesting proposal! Thanks for putting it together.

Thanks. BTW part of the reason to propose this was the new gcc/gdb
expression support for C as recently posted to the gcc and gdb lists:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01286.html
https://sourceware.org/ml/gdb-patches/2014-05/msg00287.html
Having the actual alignment used around makes it more useful/reliable.

> I thought I would mention that Ada allows the user to specify
> stricter alignments for objects too. And also, GNAT sometimes
> decides on its own to use stricter alignments for certain objects.
> Perhaps we might want to add Ada as an another example where
> such source-level requirements can be used? It is not strictly
> necessary but I have a feeling that it would convey the idea
> that the concept is used a little more widely than just through
> C11 and GNU extensions.

Thanks, I didn't know that. The proposal was certainly written with the
above and the description C11 in mind. One thing I wanted to make clear
was that a producer only needs to add the alignment if it is different
from the default alignment as used for the language and abi. And that
the producer should only add the alignment actually used (since in C11
you can add multiple alignment requests for the same type but only the
strictest is used). Adding an example for both C11 and Ada is probably a
good idea in case such assumptions might be similar (or different)
between the languages.

> I don't understand yet why you think that having a new TAG
> is a better approach. Is that because you think the compiler
> will generate the debug info for the base type regardless,
> and so having a new TAG with just that attribute and a reference
> to the base type would save a little bit of space? Or maybe
> it better follows how other modifiers such as "volatile" are
> being described? (I just realized this while typing this email)

Yes, both of those reasons. I was going through all the TAGs that might
carry an alignment attribute and then stumbled upon the type modifier
TAGs like volatile and realized that was a more direct fit instead of
adding a separate attribute only.

> > DW_TAG_aligned_type). Figure 15 Type modifier tags add:
> > DW_TAG_aligned_type non-default alignment requirements of type.
> 
> Maybe it's just because of the formatting that got lost, but
> I don't understand what's being added.

Michael was so nice to send me a copy of the proposal as saved in the
web-submission-system that has most formatting as I originally submitted
it retained. Attached below. Hopefully that is more readable.

As Michael points out the official deadline for new proposals for DWARF
5 has passed. So maybe some of the later proposals don't make it for
DWARF 5.0 final if the committee is very strict about the dates. But the
important thing is that we review and discuss the proposal and make sure
any (GNU) extensions will be as close as possible to what gets adopted
into the standard eventually.

I'll try to prototype an implementation for GCC this week and see what
it looks like in practice so we can discuss things a bit more
concretely.

BTW. It would be nice if the sources of the spec were available. Then we
could just exchange patches, which might be easier to read in context.

Cheers,

Mark
-------------- next part --------------
An embedded message was scrubbed...
From: Michael Eager <eager@eagercon.com>
Subject: Re: Dwarf Comment Submission
Date: Thu, 29 May 2014 00:34:19 -0700
Size: 5058
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140602/824006bd/attachment.eml>


From brobecker@adacore.com  Mon Jun  2 14:40:48 2014
From: brobecker@adacore.com (Joel Brobecker)
Date: Mon, 2 Jun 2014 07:40:48 -0700
Subject: [Dwarf-Discuss] Proposal to add DW_AT_alignment
In-Reply-To: <1401710834.4030.53.camel@bordewijk.wildebeest.org>
References: <1400160549.4005.40.camel@bordewijk.wildebeest.org>
	<1401287172.4106.110.camel@bordewijk.wildebeest.org>
	<20140528233353.GQ4265@adacore.com>
	<1401710834.4030.53.camel@bordewijk.wildebeest.org>
Message-ID: <20140602144048.GA30686@adacore.com>

> Thanks, I didn't know that. The proposal was certainly written with the
> above and the description C11 in mind. One thing I wanted to make clear
> was that a producer only needs to add the alignment if it is different
> from the default alignment as used for the language and abi. And that
> the producer should only add the alignment actually used (since in C11
> you can add multiple alignment requests for the same type but only the
> strictest is used). Adding an example for both C11 and Ada is probably a
> good idea in case such assumptions might be similar (or different)
> between the languages.

AFAICT, the wording was fine also for Ada.

> As Michael points out the official deadline for new proposals for DWARF
> 5 has passed. So maybe some of the later proposals don't make it for
> DWARF 5.0 final if the committee is very strict about the dates. But the
> important thing is that we review and discuss the proposal and make sure
> any (GNU) extensions will be as close as possible to what gets adopted
> into the standard eventually.

Agreed. Even if it does not make it in v5, it'll be just as good if
it show up in the issue tracker as reviewed and accepted.

-- 
Joel


From derodat@adacore.com  Tue Jun 10 09:29:07 2014
From: derodat@adacore.com (Pierre-Marie de Rodat)
Date: Tue, 10 Jun 2014 11:29:07 +0200
Subject: [Dwarf-Discuss] About self-referencial sized types
In-Reply-To: <20140515164252.GP10386@tucnak.redhat.com>
References: <5357BFD8.6030307@adacore.com>
	<0377C58828D86C4588AEEC42FC3B85A71D8679BB@IRSMSX105.ger.corp.intel.com>
	<537363E1.9010503@adacore.com>
	<20140515143018.GN10386@tucnak.redhat.com>
	<5374ED3A.4010001@adacore.com>
	<20140515164252.GP10386@tucnak.redhat.com>
Message-ID: <5396CFE3.40102@adacore.com>

On 05/15/2014 06:42 PM, Jakub Jelinek wrote:
>> Yes, I've actually already started to work with this lang-hook so we
>> can master the DWARF information output for Ada array types (very
>> useful!). However, it does not solve the issue of knowing what DWARF
>> operations to output in order to compute the bounds of VLAs
>> *without* descriptors. (see the end of my 05/14/2014 mail)
>
> You still build some trees in that langhook that describe the bounds etc.
> and dwarf2out.c just transforms those trees into DWARF4 expression opcodes.

Absolutely. In my use case, dwarf2out.c currently doesn't know how to 
translate trees from the Ada frontend into DWARF opcodes. I started this 
thread in order to know how it should do so.

-- 
Pierre-Marie de Rodat



From derodat@adacore.com  Tue Jun 10 09:29:33 2014
From: derodat@adacore.com (Pierre-Marie de Rodat)
Date: Tue, 10 Jun 2014 11:29:33 +0200
Subject: [Dwarf-Discuss] About self-referencial sized types
In-Reply-To: <0377C58828D86C4588AEEC42FC3B85A71D86EC39@IRSMSX105.ger.corp.intel.com>
References: <5357BFD8.6030307@adacore.com>
	<0377C58828D86C4588AEEC42FC3B85A71D8679BB@IRSMSX105.ger.corp.intel.com>
	<537363E1.9010503@adacore.com>
	<0377C58828D86C4588AEEC42FC3B85A71D86E3F4@IRSMSX105.ger.corp.intel.com>
	<5374EB9C.3010103@adacore.com>
	<0377C58828D86C4588AEEC42FC3B85A71D86EC39@IRSMSX105.ger.corp.intel.com>
Message-ID: <5396CFFD.2050706@adacore.com>

On 05/16/2014 03:00 PM, Agovic, Sanimir wrote:
> Indeed, therefore you have to reference a DW_TAG_variable. But
> this introduces a type/variable dependency. So a record type maps
> to a single variable, you end up with a 1:1 relation for this kind of
> types.

The size of the debug information is already an issue, so I guess such 
1:1 relations would make things worse. ;-)

> Unfortunately gdb only allows constant offsets or constant dwarf expressions.

>> [...]
>> ... It would work pretty well, actually! I'm not sure if this would
>> really be the way to go:
>>
> It is indeed quite hackish and we should rather add the necessary bits
> to gdb.

Agreed.

> The problem is that the member offset depend on runtime information similar
> to sizeof which needs to be evaluated at runtime if the operand is a vla.
>
> Given the following snippet:
>
> 	struct foo {int a[n], int b[i];};
>
> 	&((struct foo *)0)->b;
>
> What value do you expect here? And should the value be different if it is
> evaluated at runtime e.g. &f.b - &f.a?

I cannot tell for C, but the corresponding expression is supposed to 
raise a Constraint_Error exception in Ada (this is how all null pointer 
deferences are supposed to behave).

-- 
Pierre-Marie de Rodat


From derodat@adacore.com  Tue Jun 10 09:30:01 2014
From: derodat@adacore.com (Pierre-Marie de Rodat)
Date: Tue, 10 Jun 2014 11:30:01 +0200
Subject: [Dwarf-Discuss] About self-referencial sized types
In-Reply-To: <20140527161615.GA18842@toad.ccur.com>
References: <5357BFD8.6030307@adacore.com>
	<20140527161615.GA18842@toad.ccur.com>
Message-ID: <5396D019.3000308@adacore.com>

Todd,

On 05/27/2014 06:16 PM, Todd Allen wrote:
> Sorry for the last response on this.  But perhaps an example from our Ada
> compiler will help you.

Well, thank you very much for this!

> Anyway, the significant thing is that we're not referencing "n" directly, but
> rather the stored values for the upper bound.  If you store the result of
> max(0,n) somewhere, you could reference it directly.  For the case of general
> expression upper bounds, you'd have to store the values somewhere (freeze them)
> in case they might produce different results on subsequent evaluations.  But I
> don't know if the max(0,n) might be a special case where you don't do that.

That's interesting. Unfortunately, we do not store the value of the 
upper bounds in the record (nor anywhere else): the only way to get it 
at runtime is to compute it from the discriminants. The discriminants 
are the only runtime arguments that can determine the array bounds, so 
there is no risk that the bound expressions would produce different 
results sometimes.

-- 
Pierre-Marie de Rodat


From ramana.venkat83@gmail.com  Wed Jun 11 06:54:29 2014
From: ramana.venkat83@gmail.com (Ramana)
Date: Wed, 11 Jun 2014 12:24:29 +0530
Subject: [Dwarf-Discuss] Regarding concrete inlined and out-of-line inlined
	instances
Message-ID: <CAF4ZLkuxwzYwysqtNHhoprq_Lbunfw16YgnLvUKPCMpr5ncWfQ@mail.gmail.com>

Hi,

I have the below debug information (dwarf4) generated by the GCC
compiler v4.8.2 for an inlined function. Please help me with the
following query.

In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc
value (0xc0000000001b49d0) is overlapping with the address range i.e.
DW_AT_low_pc (0xc0000000001b4980) and DW_AT_high_pc
(0xc0000000001b4a60) of the out-of-line instance root entry. Is this
overlapping legitimate and how?

 <1><1038302>: Abbrev Number: 51 (DW_TAG_subprogram)
    <1038303>   DW_AT_name        : (indirect string, offset:
0x7a615): ext2_lookup
    <1038307>   DW_AT_decl_file   : 1
    <1038308>   DW_AT_decl_line   : 58
    <1038309>   DW_AT_prototyped  : 1
    <103830a>   DW_AT_type        : <0x10330af>
    <103830e>   DW_AT_inline      : 1   (inlined)
    <103830f>   DW_AT_sibling     : <0x1038359>
 <2><1038313>: Abbrev Number: 52 (DW_TAG_formal_parameter)
    <1038314>   DW_AT_name        : dir
    <1038318>   DW_AT_decl_file   : 1
    <1038319>   DW_AT_decl_line   : 58
    <103831a>   DW_AT_type        : <0x103331d>
 <2><103831e>: Abbrev Number: 56 (DW_TAG_formal_parameter)
    <103831f>   DW_AT_name        : (indirect string, offset: 0x4fb14): dentry
    <1038323>   DW_AT_decl_file   : 1
    <1038324>   DW_AT_decl_line   : 58
    <1038325>   DW_AT_type        : <0x10330af>
 <2><1038329>: Abbrev Number: 56 (DW_TAG_formal_parameter)
    <103832a>   DW_AT_name        : (indirect string, offset: 0x1a72d5): flags
    <103832e>   DW_AT_decl_file   : 1
    <103832f>   DW_AT_decl_line   : 58
    <1038330>   DW_AT_type        : <0x1030083>
 <2><1038334>: Abbrev Number: 61 (DW_TAG_variable)
    <1038335>   DW_AT_name        : (indirect string, offset: 0x7a533): inode
    <1038339>   DW_AT_decl_file   : 1
    <103833a>   DW_AT_decl_line   : 60
    <103833b>   DW_AT_type        : <0x103331d>
 <2><103833f>: Abbrev Number: 57 (DW_TAG_variable)
    <1038340>   DW_AT_name        : ino
    <1038344>   DW_AT_decl_file   : 1
    <1038345>   DW_AT_decl_line   : 61
    <1038346>   DW_AT_type        : <0x1030243>
 <2><103834a>: Abbrev Number: 62 (DW_TAG_variable)
    <103834b>   DW_AT_name        : (indirect string, offset: 0xdd81): __func__
    <103834f>   DW_AT_type        : <0x1038369>
    <1038353>   DW_AT_artificial  : 1
    <1038354>   DW_AT_const_value : (indirect string, offset:
0x7a615): ext2_lookup
 <1><1038359>: Abbrev Number: 8 (DW_TAG_array_type)
    <103835a>   DW_AT_type        : <0x1030168>
    <103835e>   DW_AT_sibling     : <0x1038369>
 <2><1038362>: Abbrev Number: 9 (DW_TAG_subrange_type)
    <1038363>   DW_AT_type        : <0x1030129>
    <1038367>   DW_AT_upper_bound : 11
 <1><1038369>: Abbrev Number: 11 (DW_TAG_const_type)
    <103836a>   DW_AT_type        : <0x1038359>
..............................
...
................................. (some intermediate DIE entries)
.................................
 <1><10397ce>: Abbrev Number: 92 (DW_TAG_subprogram)
    <10397cf>   DW_AT_abstract_origin: <0x1038302>
    <10397d3>   DW_AT_low_pc      : 0xc0000000001b4980
    <10397db>   DW_AT_high_pc     : 0xc0000000001b4a60
    <10397e3>   DW_AT_frame_base  : 0x53243a    (location list)
    <10397e7>   DW_AT_GNU_all_call_sites: 1
    <10397e8>   DW_AT_sibling     : <0x10398eb>
 <2><10397ec>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397ed>   DW_AT_abstract_origin: <0x1038313>
    <10397f1>   DW_AT_location    : 0x5324c5    (location list)
 <2><10397f5>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397f6>   DW_AT_abstract_origin: <0x103831e>
    <10397fa>   DW_AT_location    : 0x53254d    (location list)
 <2><10397fe>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397ff>   DW_AT_abstract_origin: <0x1038329>
    <1039803>   DW_AT_location    : 0x5325e8    (location list)
 <2><1039807>: Abbrev Number: 93 (DW_TAG_variable)
    <1039808>   DW_AT_abstract_origin: <0x1038334>
 <2><103980c>: Abbrev Number: 93 (DW_TAG_variable)
    <103980d>   DW_AT_abstract_origin: <0x103833f>
 <2><1039811>: Abbrev Number: 94 (DW_TAG_variable)
    <1039812>   DW_AT_abstract_origin: <0x103834a>
    <1039816>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
a0         (DW_OP_addr: c000000000793ea0)
<2><1039820>: Abbrev Number: 95 (DW_TAG_inlined_subroutine)
    <1039821>   DW_AT_abstract_origin: <0x1038302>
    <1039825>   DW_AT_entry_pc    : 0xc0000000001b49d0
    <103982d>   DW_AT_ranges      : 0x14a0c0
    <1039831>   DW_AT_call_file   : 1
    <1039832>   DW_AT_call_line   : 58
 <3><1039833>: Abbrev Number: 96 (DW_TAG_formal_parameter)
    <1039834>   DW_AT_abstract_origin: <0x103831e>
 <3><1039838>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <1039839>   DW_AT_abstract_origin: <0x1038313>
    <103983d>   DW_AT_location    : 0x53264a    (location list)
 <3><1039841>: Abbrev Number: 86 (DW_TAG_lexical_block)
    <1039842>   DW_AT_ranges      : 0x14a0f0
 <4><1039846>: Abbrev Number: 87 (DW_TAG_variable)
    <1039847>   DW_AT_abstract_origin: <0x1038334>
    <103984b>   DW_AT_location    : 0x532696    (location list)
 <4><103984f>: Abbrev Number: 87 (DW_TAG_variable)
    <1039850>   DW_AT_abstract_origin: <0x103833f>
    <1039854>   DW_AT_location    : 0x5326f4    (location list)
 <4><1039858>: Abbrev Number: 96 (DW_TAG_formal_parameter)
    <1039859>   DW_AT_abstract_origin: <0x1038329>
 <4><103985d>: Abbrev Number: 94 (DW_TAG_variable)
    <103985e>   DW_AT_abstract_origin: <0x103834a>
    <1039862>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
a0         (DW_OP_addr: c000000000793ea0)

Thank you,
Venkata Ramanaiah N


From ccoutant@gmail.com  Wed Jun 11 21:21:18 2014
From: ccoutant@gmail.com (Cary Coutant)
Date: Wed, 11 Jun 2014 14:21:18 -0700
Subject: [Dwarf-Discuss] Regarding concrete inlined and out-of-line
 inlined instances
In-Reply-To: <CAF4ZLkuxwzYwysqtNHhoprq_Lbunfw16YgnLvUKPCMpr5ncWfQ@mail.gmail.com>
References: <CAF4ZLkuxwzYwysqtNHhoprq_Lbunfw16YgnLvUKPCMpr5ncWfQ@mail.gmail.com>
Message-ID: <CAJimCsGjkFqPdZVhtxW-MuGsZDtmBGiUtmSiHVqyuR3tCRPVAg@mail.gmail.com>

> In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc
> value (0xc0000000001b49d0) is overlapping with the address range i.e.
> DW_AT_low_pc (0xc0000000001b4980) and DW_AT_high_pc
> (0xc0000000001b4a60) of the out-of-line instance root entry. Is this
> overlapping legitimate and how?

Is this a recursive inlined call? The DW_TAG_subprogram DIE at
<10397ce> represents an out-of-line copy of ext2_lookup. The
DW_TAG_inlined_subroutine DIE at <1039820> represents an inlined copy
of the same subprogram, inlined into the out-of-line copy. It makes
sense that the entry PC for an inlined subroutine would be within the
PC range of the calling subprogram. If you look at the range table
entry at <0x14a0c0>, you will be able to see the ranges of PCs within
the top-level subprogram that actually belong to the inlined copy.

It appears that the subprogram is defined at line 58 in the source
file, and the inlined call also occurs at line 58, so something looks
fishy. What does the source code look like?

-cary

>  <1><1038302>: Abbrev Number: 51 (DW_TAG_subprogram)
>     <1038303>   DW_AT_name        : (indirect string, offset:
> 0x7a615): ext2_lookup
>     <1038307>   DW_AT_decl_file   : 1
>     <1038308>   DW_AT_decl_line   : 58
>     <1038309>   DW_AT_prototyped  : 1
>     <103830a>   DW_AT_type        : <0x10330af>
>     <103830e>   DW_AT_inline      : 1   (inlined)
>     <103830f>   DW_AT_sibling     : <0x1038359>
>  <2><1038313>: Abbrev Number: 52 (DW_TAG_formal_parameter)
>     <1038314>   DW_AT_name        : dir
>     <1038318>   DW_AT_decl_file   : 1
>     <1038319>   DW_AT_decl_line   : 58
>     <103831a>   DW_AT_type        : <0x103331d>
>  <2><103831e>: Abbrev Number: 56 (DW_TAG_formal_parameter)
>     <103831f>   DW_AT_name        : (indirect string, offset: 0x4fb14): dentry
>     <1038323>   DW_AT_decl_file   : 1
>     <1038324>   DW_AT_decl_line   : 58
>     <1038325>   DW_AT_type        : <0x10330af>
>  <2><1038329>: Abbrev Number: 56 (DW_TAG_formal_parameter)
>     <103832a>   DW_AT_name        : (indirect string, offset: 0x1a72d5): flags
>     <103832e>   DW_AT_decl_file   : 1
>     <103832f>   DW_AT_decl_line   : 58
>     <1038330>   DW_AT_type        : <0x1030083>
>  <2><1038334>: Abbrev Number: 61 (DW_TAG_variable)
>     <1038335>   DW_AT_name        : (indirect string, offset: 0x7a533): inode
>     <1038339>   DW_AT_decl_file   : 1
>     <103833a>   DW_AT_decl_line   : 60
>     <103833b>   DW_AT_type        : <0x103331d>
>  <2><103833f>: Abbrev Number: 57 (DW_TAG_variable)
>     <1038340>   DW_AT_name        : ino
>     <1038344>   DW_AT_decl_file   : 1
>     <1038345>   DW_AT_decl_line   : 61
>     <1038346>   DW_AT_type        : <0x1030243>
>  <2><103834a>: Abbrev Number: 62 (DW_TAG_variable)
>     <103834b>   DW_AT_name        : (indirect string, offset: 0xdd81): __func__
>     <103834f>   DW_AT_type        : <0x1038369>
>     <1038353>   DW_AT_artificial  : 1
>     <1038354>   DW_AT_const_value : (indirect string, offset:
> 0x7a615): ext2_lookup
>  <1><1038359>: Abbrev Number: 8 (DW_TAG_array_type)
>     <103835a>   DW_AT_type        : <0x1030168>
>     <103835e>   DW_AT_sibling     : <0x1038369>
>  <2><1038362>: Abbrev Number: 9 (DW_TAG_subrange_type)
>     <1038363>   DW_AT_type        : <0x1030129>
>     <1038367>   DW_AT_upper_bound : 11
>  <1><1038369>: Abbrev Number: 11 (DW_TAG_const_type)
>     <103836a>   DW_AT_type        : <0x1038359>
> ..............................
> ...
> ................................. (some intermediate DIE entries)
> .................................
>  <1><10397ce>: Abbrev Number: 92 (DW_TAG_subprogram)
>     <10397cf>   DW_AT_abstract_origin: <0x1038302>
>     <10397d3>   DW_AT_low_pc      : 0xc0000000001b4980
>     <10397db>   DW_AT_high_pc     : 0xc0000000001b4a60
>     <10397e3>   DW_AT_frame_base  : 0x53243a    (location list)
>     <10397e7>   DW_AT_GNU_all_call_sites: 1
>     <10397e8>   DW_AT_sibling     : <0x10398eb>
>  <2><10397ec>: Abbrev Number: 70 (DW_TAG_formal_parameter)
>     <10397ed>   DW_AT_abstract_origin: <0x1038313>
>     <10397f1>   DW_AT_location    : 0x5324c5    (location list)
>  <2><10397f5>: Abbrev Number: 70 (DW_TAG_formal_parameter)
>     <10397f6>   DW_AT_abstract_origin: <0x103831e>
>     <10397fa>   DW_AT_location    : 0x53254d    (location list)
>  <2><10397fe>: Abbrev Number: 70 (DW_TAG_formal_parameter)
>     <10397ff>   DW_AT_abstract_origin: <0x1038329>
>     <1039803>   DW_AT_location    : 0x5325e8    (location list)
>  <2><1039807>: Abbrev Number: 93 (DW_TAG_variable)
>     <1039808>   DW_AT_abstract_origin: <0x1038334>
>  <2><103980c>: Abbrev Number: 93 (DW_TAG_variable)
>     <103980d>   DW_AT_abstract_origin: <0x103833f>
>  <2><1039811>: Abbrev Number: 94 (DW_TAG_variable)
>     <1039812>   DW_AT_abstract_origin: <0x103834a>
>     <1039816>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
> a0         (DW_OP_addr: c000000000793ea0)
> <2><1039820>: Abbrev Number: 95 (DW_TAG_inlined_subroutine)
>     <1039821>   DW_AT_abstract_origin: <0x1038302>
>     <1039825>   DW_AT_entry_pc    : 0xc0000000001b49d0
>     <103982d>   DW_AT_ranges      : 0x14a0c0
>     <1039831>   DW_AT_call_file   : 1
>     <1039832>   DW_AT_call_line   : 58
>  <3><1039833>: Abbrev Number: 96 (DW_TAG_formal_parameter)
>     <1039834>   DW_AT_abstract_origin: <0x103831e>
>  <3><1039838>: Abbrev Number: 70 (DW_TAG_formal_parameter)
>     <1039839>   DW_AT_abstract_origin: <0x1038313>
>     <103983d>   DW_AT_location    : 0x53264a    (location list)
>  <3><1039841>: Abbrev Number: 86 (DW_TAG_lexical_block)
>     <1039842>   DW_AT_ranges      : 0x14a0f0
>  <4><1039846>: Abbrev Number: 87 (DW_TAG_variable)
>     <1039847>   DW_AT_abstract_origin: <0x1038334>
>     <103984b>   DW_AT_location    : 0x532696    (location list)
>  <4><103984f>: Abbrev Number: 87 (DW_TAG_variable)
>     <1039850>   DW_AT_abstract_origin: <0x103833f>
>     <1039854>   DW_AT_location    : 0x5326f4    (location list)
>  <4><1039858>: Abbrev Number: 96 (DW_TAG_formal_parameter)
>     <1039859>   DW_AT_abstract_origin: <0x1038329>
>  <4><103985d>: Abbrev Number: 94 (DW_TAG_variable)
>     <103985e>   DW_AT_abstract_origin: <0x103834a>
>     <1039862>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
> a0         (DW_OP_addr: c000000000793ea0)
>
> Thank you,
> Venkata Ramanaiah N
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


From ramana.venkat83@gmail.com  Thu Jun 12 11:00:34 2014
From: ramana.venkat83@gmail.com (Ramana)
Date: Thu, 12 Jun 2014 16:30:34 +0530
Subject: [Dwarf-Discuss] Regarding concrete inlined and out-of-line
 inlined instances
In-Reply-To: <CAJimCsGjkFqPdZVhtxW-MuGsZDtmBGiUtmSiHVqyuR3tCRPVAg@mail.gmail.com>
References: <CAF4ZLkuxwzYwysqtNHhoprq_Lbunfw16YgnLvUKPCMpr5ncWfQ@mail.gmail.com>
	<CAJimCsGjkFqPdZVhtxW-MuGsZDtmBGiUtmSiHVqyuR3tCRPVAg@mail.gmail.com>
Message-ID: <CAF4ZLkvN0pjxiX2pxuj2uSuPbRoDPViL-QEPai_aAqUNb0Qs3w@mail.gmail.com>

Hi Cary,

Thanks for your comments.

> Is this a recursive inlined call?

No, it is not a recursive call.

> It appears that the subprogram is defined at line 58 in the source
> file, and the inlined call also occurs at line 58, so something looks
> fishy. What does the source code look like?

You are right that ext2_lookup is defined at line 58 but there is no
call at the same line. Other than that, ext2_lookup is referenced as
follows in the same C file.

At line 383

const struct inode_operations ext2_dir_inode_operations = {
        .create         = ext2_create,
        .lookup         = ext2_lookup,
...............
...............
}

At line 126
        if (!root->d_inode ||
            !root->d_inode->i_op ||
            !root->d_inode->i_op->lookup ||
            ...................)

At line 782
        if (!subdir->d_inode->i_op ||
            ..........
            !subdir->d_inode->i_op->lookup ||
            .........)

At line 1317
        old = dir->i_op->lookup(dir, dentry, flags);

Also, if we closely look at the debug information tables (pasted below
again), the DW_AT_location attribute is not generated either for all
formal parameters in the concrete inlined instance tree OR for all
function local variables in the out-of-line inlined instance tree.
Isn't that something abnormal?

Following is the relevant piece of ext2_lookup definition to know the
arguments and local variables.

static struct dentry *ext2_lookup(struct inode * dir, struct dentry
*dentry, unsigned int flags)
{
        struct inode * inode;
        ino_t ino;
        .............
}

 <1><10397ce>: Abbrev Number: 92 (DW_TAG_subprogram)
    <10397cf>   DW_AT_abstract_origin: <0x1038302>
    <10397d3>   DW_AT_low_pc      : 0xc0000000001b4980
    <10397db>   DW_AT_high_pc     : 0xc0000000001b4a60
    <10397e3>   DW_AT_frame_base  : 0x53243a    (location list)
    <10397e7>   DW_AT_GNU_all_call_sites: 1
    <10397e8>   DW_AT_sibling     : <0x10398eb>
 <2><10397ec>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397ed>   DW_AT_abstract_origin: <0x1038313>
    <10397f1>   DW_AT_location    : 0x5324c5    (location list)
 <2><10397f5>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397f6>   DW_AT_abstract_origin: <0x103831e>
    <10397fa>   DW_AT_location    : 0x53254d    (location list)
 <2><10397fe>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <10397ff>   DW_AT_abstract_origin: <0x1038329>
    <1039803>   DW_AT_location    : 0x5325e8    (location list)
 <2><1039807>: Abbrev Number: 93 (DW_TAG_variable)
    <1039808>   DW_AT_abstract_origin: <0x1038334>
 <2><103980c>: Abbrev Number: 93 (DW_TAG_variable)
    <103980d>   DW_AT_abstract_origin: <0x103833f>
 <2><1039811>: Abbrev Number: 94 (DW_TAG_variable)
    <1039812>   DW_AT_abstract_origin: <0x103834a>
    <1039816>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
a0         (DW_OP_addr: c000000000793ea0)
<2><1039820>: Abbrev Number: 95 (DW_TAG_inlined_subroutine)
    <1039821>   DW_AT_abstract_origin: <0x1038302>
    <1039825>   DW_AT_entry_pc    : 0xc0000000001b49d0
    <103982d>   DW_AT_ranges      : 0x14a0c0
    <1039831>   DW_AT_call_file   : 1
    <1039832>   DW_AT_call_line   : 58
 <3><1039833>: Abbrev Number: 96 (DW_TAG_formal_parameter)
    <1039834>   DW_AT_abstract_origin: <0x103831e>
 <3><1039838>: Abbrev Number: 70 (DW_TAG_formal_parameter)
    <1039839>   DW_AT_abstract_origin: <0x1038313>
    <103983d>   DW_AT_location    : 0x53264a    (location list)
 <3><1039841>: Abbrev Number: 86 (DW_TAG_lexical_block)
    <1039842>   DW_AT_ranges      : 0x14a0f0
 <4><1039846>: Abbrev Number: 87 (DW_TAG_variable)
    <1039847>   DW_AT_abstract_origin: <0x1038334>
    <103984b>   DW_AT_location    : 0x532696    (location list)
 <4><103984f>: Abbrev Number: 87 (DW_TAG_variable)
    <1039850>   DW_AT_abstract_origin: <0x103833f>
    <1039854>   DW_AT_location    : 0x5326f4    (location list)
 <4><1039858>: Abbrev Number: 96 (DW_TAG_formal_parameter)
    <1039859>   DW_AT_abstract_origin: <0x1038329>
 <4><103985d>: Abbrev Number: 94 (DW_TAG_variable)
    <103985e>   DW_AT_abstract_origin: <0x103834a>
    <1039862>   DW_AT_location    : 9 byte block: 3 c0 0 0 0 0 79 3e
a0         (DW_OP_addr: c000000000793ea0)


Thank you,
Venkata Ramanaiah N


