From simon.marchi@ericsson.com  Wed Nov 22 20:56:48 2017
From: simon.marchi@ericsson.com (Simon Marchi)
Date: Wed, 22 Nov 2017 15:56:48 -0500
Subject: [Dwarf-Discuss] DWARF: Hierarchies of abstract and concrete DIE
 instance trees
In-Reply-To: <11e1d641-3d89-23ba-d306-f840b756a79e@ericsson.com>
References: <11e1d641-3d89-23ba-d306-f840b756a79e@ericsson.com>
Message-ID: <c53e552a-6771-0aa8-aa0c-a513821aef66@ericsson.com>

On 2017-09-15 08:02 AM, Simon Marchi wrote:
> Hi all,
> 
> First, a bit of context.  I'm currently investigating why GDB doesn't show
> optimized out variables in "info locals".  The fix appears simple [1], but one
> test case starts failing.  The symptom is that the local variable of func1, which
> is inlined in main, appears twice (at least when compiled with GCC 5.4 and 7.1):
> 
> (gdb) bt
> #0  bar () at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-markers.c:27
> #1  0x00000000004005b0 in func1 (arg1=0) at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:38
> #2  main () at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:55
> (gdb) frame
> #1  0x00000000004005b0 in func1 (arg1=0) at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:38
> (gdb) info locals
> array = {... the right value ... }
> array = <optimized out>
> 
> Note that in this case, array is not actually optimized out.  What I'm seeing
> when debugging GDB is that it creates two "array" symbols while parsing the
> DWARF debug info.  The interesting parts of the DWARF are:
> 
> - the abstract instance tree (thing that gets inlined)
> 
>  <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
>     <2a>   DW_AT_external    : 1
>     <2a>   DW_AT_name        : (indirect string, offset: 0x70): func1
>     <2e>   DW_AT_decl_file   : 1
>     <2f>   DW_AT_decl_line   : 32
>     <30>   DW_AT_prototyped  : 1
>     <30>   DW_AT_type        : <0x50>
>     <34>   DW_AT_inline      : 3        (declared as inline and inlined)
>     <35>   DW_AT_sibling     : <0x50>
>  ...
>  <2><44>: Abbrev Number: 4 (DW_TAG_variable)
>     <45>   DW_AT_name        : (indirect string, offset: 0x50): array
>     <49>   DW_AT_decl_file   : 1
>     <4a>   DW_AT_decl_line   : 34
>     <4b>   DW_AT_type        : <0x57>
> 
> - the concrete instance tree (the place where it gets inlined)
> 
>  <2><9e>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
>     <9f>   DW_AT_abstract_origin: <0x29>
>     <a3>   DW_AT_low_pc      : 0x400585
>     <ab>   DW_AT_high_pc     : 0x4c
>     <b3>   DW_AT_call_file   : 1
>     <b4>   DW_AT_call_line   : 55
>  ...
>  <3><be>: Abbrev Number: 13 (DW_TAG_lexical_block)
>     <bf>   DW_AT_low_pc      : 0x400585
>     <c7>   DW_AT_high_pc     : 0x4c
>  <4><cf>: Abbrev Number: 14 (DW_TAG_variable)
>     <d0>   DW_AT_abstract_origin: <0x44>
>     <d4>   DW_AT_location    : 3 byte block: 91 e0 7d   (DW_OP_fbreg: -288)
> 
> 
> The interesting thing here is that the hierarchies of the abstract and concrete
> DIE trees are not exactly the same.  In the abstract tree the variable is a
> direct child of the subprogram.  In the concrete tree, a lexical block is
> inserted between the inlined subroutine and the variable.  For the visuals:
> 
>                                             child of
> Abstract tree:  subprogram <------------------------------------- variable
>                     A                                                A
>                     |                                                |
>         instance of |                                    instance of |
>                     |                                                |
>                     |         child of                  child of     |
> Concrete tree:  inlined sub <---------- lexical block <---------- variable
> 
> When GDB parses that DWARF, it first creates a symbol when visiting the
> concrete instance of the variable.  It then tries to inherit everything from
> the inlined subroutine's abstract origin (including children) that wasn't
> already explicitly referenced by its children.  For some reason, GDB doesn't
> track properly that the abstract variable has already referenced, and creates a
> second symbol.  That symbol coming from the abstract variable DIE doesn't have
> a location, that's it appears as "optimized out".
> 
> My question is: should the hierarchies of the abstract and concrete trees match
> exactly (IOW, should the concrete child's abstract origin's parent always be
> the same as its parent's abstract origin).  And therefore, is this example
> "legal" DWARF and GDB bug, or invalid DWARF and a GCC bug (or neither and I'm
> completely lost).
> 
> With Clang, the lexical block is not there, and everything works as expected.
> 
> Thanks!
> 
> Simon
> 
> [1] https://github.com/simark/binutils-gdb/commit/3d16834e2d886d2dd57f93d27b39a4099ffc98fc.patch
> 

Hi,

I had an email discussion some time ago with some gcc developers (Nathan Sidwell,
Richard Biener, Jason Merill).  I though I would post the important parts here,
to act as a reference.

Richard said:

> I think the lexical block is just the function scope itself and the inliner
> inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine.
> I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block
> but use the emitted DW_TAG_inlined_subroutine for that.
>
> Not sure if I remember the details correctly.
>
> I don't think the DWARF is invalid btw, with early LTO debug we have plenty of
> abstract origins where source and destination context don't match 1:1.  We're
> just using it as a "get some more info from this DIE" link which I think is
> all that is documented as semantics (though the 'inline' term pops up too
> often there and the relation to DW_AT_specification is unclear to me though
> the latter is restricted to DW_TAG_subroutine AFAIR).

Jason said (replying to Richard):

>> I think the lexical block is just the function scope itself and the inliner
>> inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine.
>> I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block
>> but use the emitted DW_TAG_inlined_subroutine for that.
>
> Agreed.  It's curious that we would generate the lexical block in the
> inlined instance and not the abstract.
>
>>  I don't think the DWARF is invalid btw, with early LTO debug we have plenty of
>>  abstract origins where source and destination context don't match 1:1.  We're
>>  just using it as a "get some more info from this DIE" link which I think is
>>  all that is documented as semantics (though the 'inline' term pops up too
>>  often there and the relation to DW_AT_specification is unclear to me though
>>  the latter is restricted to DW_TAG_subroutine AFAIR).
>
> Also agreed, GDB ought to be able to handle this situation.
>
> So, bugs on both sides...

So the conclusion seems to be that the lexical block might be useless, but it
doesn't make the DWARF invalid, and GDB should be able to cope with it.

Thanks,

Simon


From eager@eagercon.com  Wed Nov 22 22:04:18 2017
From: eager@eagercon.com (Michael Eager)
Date: Wed, 22 Nov 2017 14:04:18 -0800
Subject: [Dwarf-Discuss] DWARF: Hierarchies of abstract and concrete DIE
 instance trees
In-Reply-To: <c53e552a-6771-0aa8-aa0c-a513821aef66@ericsson.com>
References: <11e1d641-3d89-23ba-d306-f840b756a79e@ericsson.com>
 <c53e552a-6771-0aa8-aa0c-a513821aef66@ericsson.com>
Message-ID: <64c1490b-6b08-50e3-c085-a5a61b251c1b@eagercon.com>

On 11/22/2017 12:56 PM, Simon Marchi wrote:
> On 2017-09-15 08:02 AM, Simon Marchi wrote:
>> Hi all,
>>
>> First, a bit of context.  I'm currently investigating why GDB doesn't show
>> optimized out variables in "info locals".  The fix appears simple [1], but one
>> test case starts failing.  The symptom is that the local variable of func1, which
>> is inlined in main, appears twice (at least when compiled with GCC 5.4 and 7.1):
>>
>> (gdb) bt
>> #0  bar () at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-markers.c:27
>> #1  0x00000000004005b0 in func1 (arg1=0) at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:38
>> #2  main () at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:55
>> (gdb) frame
>> #1  0x00000000004005b0 in func1 (arg1=0) at /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.opt/inline-locals.c:38
>> (gdb) info locals
>> array = {... the right value ... }
>> array = <optimized out>
>>
>> Note that in this case, array is not actually optimized out.  What I'm seeing
>> when debugging GDB is that it creates two "array" symbols while parsing the
>> DWARF debug info.  The interesting parts of the DWARF are:
>>
>> - the abstract instance tree (thing that gets inlined)
>>
>>   <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
>>      <2a>   DW_AT_external    : 1
>>      <2a>   DW_AT_name        : (indirect string, offset: 0x70): func1
>>      <2e>   DW_AT_decl_file   : 1
>>      <2f>   DW_AT_decl_line   : 32
>>      <30>   DW_AT_prototyped  : 1
>>      <30>   DW_AT_type        : <0x50>
>>      <34>   DW_AT_inline      : 3        (declared as inline and inlined)
>>      <35>   DW_AT_sibling     : <0x50>
>>   ...
>>   <2><44>: Abbrev Number: 4 (DW_TAG_variable)
>>      <45>   DW_AT_name        : (indirect string, offset: 0x50): array
>>      <49>   DW_AT_decl_file   : 1
>>      <4a>   DW_AT_decl_line   : 34
>>      <4b>   DW_AT_type        : <0x57>
>>
>> - the concrete instance tree (the place where it gets inlined)
>>
>>   <2><9e>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
>>      <9f>   DW_AT_abstract_origin: <0x29>
>>      <a3>   DW_AT_low_pc      : 0x400585
>>      <ab>   DW_AT_high_pc     : 0x4c
>>      <b3>   DW_AT_call_file   : 1
>>      <b4>   DW_AT_call_line   : 55
>>   ...
>>   <3><be>: Abbrev Number: 13 (DW_TAG_lexical_block)
>>      <bf>   DW_AT_low_pc      : 0x400585
>>      <c7>   DW_AT_high_pc     : 0x4c
>>   <4><cf>: Abbrev Number: 14 (DW_TAG_variable)
>>      <d0>   DW_AT_abstract_origin: <0x44>
>>      <d4>   DW_AT_location    : 3 byte block: 91 e0 7d   (DW_OP_fbreg: -288)
>>
>>
>> The interesting thing here is that the hierarchies of the abstract and concrete
>> DIE trees are not exactly the same.  In the abstract tree the variable is a
>> direct child of the subprogram.  In the concrete tree, a lexical block is
>> inserted between the inlined subroutine and the variable.  For the visuals:
>>
>>                                              child of
>> Abstract tree:  subprogram <------------------------------------- variable
>>                      A                                                A
>>                      |                                                |
>>          instance of |                                    instance of |
>>                      |                                                |
>>                      |         child of                  child of     |
>> Concrete tree:  inlined sub <---------- lexical block <---------- variable
>>
>> When GDB parses that DWARF, it first creates a symbol when visiting the
>> concrete instance of the variable.  It then tries to inherit everything from
>> the inlined subroutine's abstract origin (including children) that wasn't
>> already explicitly referenced by its children.  For some reason, GDB doesn't
>> track properly that the abstract variable has already referenced, and creates a
>> second symbol.  That symbol coming from the abstract variable DIE doesn't have
>> a location, that's it appears as "optimized out".
>>
>> My question is: should the hierarchies of the abstract and concrete trees match
>> exactly (IOW, should the concrete child's abstract origin's parent always be
>> the same as its parent's abstract origin).  And therefore, is this example
>> "legal" DWARF and GDB bug, or invalid DWARF and a GCC bug (or neither and I'm
>> completely lost).
>>
>> With Clang, the lexical block is not there, and everything works as expected.
>>
>> Thanks!
>>
>> Simon
>>
>> [1] https://github.com/simark/binutils-gdb/commit/3d16834e2d886d2dd57f93d27b39a4099ffc98fc.patch
>>
> 
> Hi,
> 
> I had an email discussion some time ago with some gcc developers (Nathan Sidwell,
> Richard Biener, Jason Merill).  I though I would post the important parts here,
> to act as a reference.
> 
> Richard said:
> 
>> I think the lexical block is just the function scope itself and the inliner
>> inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine.
>> I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block
>> but use the emitted DW_TAG_inlined_subroutine for that.
>>
>> Not sure if I remember the details correctly.
>>
>> I don't think the DWARF is invalid btw, with early LTO debug we have plenty of
>> abstract origins where source and destination context don't match 1:1.  We're
>> just using it as a "get some more info from this DIE" link which I think is
>> all that is documented as semantics (though the 'inline' term pops up too
>> often there and the relation to DW_AT_specification is unclear to me though
>> the latter is restricted to DW_TAG_subroutine AFAIR).
> 
> Jason said (replying to Richard):
> 
>>> I think the lexical block is just the function scope itself and the inliner
>>> inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine.
>>> I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block
>>> but use the emitted DW_TAG_inlined_subroutine for that.
>>
>> Agreed.  It's curious that we would generate the lexical block in the
>> inlined instance and not the abstract.
>>
>>>   I don't think the DWARF is invalid btw, with early LTO debug we have plenty of
>>>   abstract origins where source and destination context don't match 1:1.  We're
>>>   just using it as a "get some more info from this DIE" link which I think is
>>>   all that is documented as semantics (though the 'inline' term pops up too
>>>   often there and the relation to DW_AT_specification is unclear to me though
>>>   the latter is restricted to DW_TAG_subroutine AFAIR).
>>
>> Also agreed, GDB ought to be able to handle this situation.
>>
>> So, bugs on both sides...
> 
> So the conclusion seems to be that the lexical block might be useless, but it
> doesn't make the DWARF invalid, and GDB should be able to cope with it.

I think that the DWARF is invalid.

In the abstract instance, the DWARF describes the source as

    int func1 (...)
    {
       int array[];
       ...
    }

The concrete instance describes a different source:

    int func1 (...)
    {
      {
        int array[];
        ...
      }
    }

These are not the same source trees and the second one does not in fact 
accurately describe the actual source.  I don't recall if there is a 
requirement in the DWARF Spec that the concrete and abstract instance 
descriptions need to match each other.  If not, I think that there 
should be.

I'd like to see an example (as Jason mentioned) where abstract and 
concrete instances do not match and where this appears to be correct. 
If LLVM is using abstract origin to mean "get info from this DIE", and 
not to mean "this is a concrete instance of this abstract definition", 
then we (on the DWARF side) need to look at how abstract origin is 
defined and whether this use is compatible with its intended use.


-- 
Michael Eager    eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306


From davea42@linuxmail.org  Wed Nov 22 22:17:25 2017
From: davea42@linuxmail.org (David Anderson)
Date: Wed, 22 Nov 2017 14:17:25 -0800
Subject: [Dwarf-Discuss] Fwd: Re: DWARF: Hierarchies of abstract and
 concrete DIE instance trees
In-Reply-To: <f9874b1a-4772-f67e-f92f-b81323abd21a@gmail.com>
References: <f9874b1a-4772-f67e-f92f-b81323abd21a@gmail.com>
Message-ID: <fbb6ff0e-c254-badf-1c1d-227585b5684a@linuxmail.org>

On 11/22/2017 12:56 PM, Simon Marchi wrote:
...
>> Agreed.  It's curious that we would generate the lexical block in the
>> inlined instance and not the abstract.
>>
>>>  I don't think the DWARF is invalid btw, with early LTO debug we have plenty of
>>>  abstract origins where source and destination context don't match 1:1.  We're
>>>  just using it as a "get some more info from this DIE" link which I think is
>>>  all that is documented as semantics (though the 'inline' term pops up too
>>>  often there and the relation to DW_AT_specification is unclear to me though
>>>  the latter is restricted to DW_TAG_subroutine AFAIR).
>> Also agreed, GDB ought to be able to handle this situation.
>>
>> So, bugs on both sides...
> So the conclusion seems to be that the lexical block might be useless, but it
> doesn't make the DWARF invalid, and GDB should be able to cope with it.

Dwarf 5, 3.3.8.1. line 16:

"Attributes and children in an abstract instance
are shared by all concrete
instances (see Section 3.3.8.2 on the next page)."

next page:
"Concrete inlined instance entries may omit attributes
that are not specific to the
concrete instance (but present in the abstract instance)
and need include only
attributes that are specific to the concrete instance
(but omitted in the abstract
instance). In place of these omitted attributes,
each concrete inlined instance
entry has a DW_AT_abstract_origin attribute that
may be used to obtain the
missing information (indirectly) from the
associated abstract instance entry. The
value of the abstract origin attribute is
a reference to the associated abstract
instance entry."

next page:-------- Forwarded Message --------
Subject: Re: [Dwarf-Discuss] DWARF: Hierarchies of abstract and concrete
DIE instance trees
Date: Wed, 22 Nov 2017 14:15:10 -0800
From: David Anderson <davea42@gmail.com>
To: dwarf-discuss at lists.dwarfstd.org


"In general, the structure and content of any
given concrete inlined instance tree
will be closely analogous to the structure
and content of its associated abstract
instance tree. There are a few exceptions:"
...
"2. Entries in the concrete instance tree which are associated with
entries in the
abstract instance tree such that neither
has a DW_AT_name attribute, and
neither is referenced by any other debugging
information entry, may be
omitted. This may happen for debugging
information entries in the abstract
instance trees that became unnecessary
in the concrete instance tree because
of additional information available there.
For example, an anonymous
variable might have been created and
described in the abstract instance tree,
but because of the actual parameters
for a particular inlined expansion, it
could be described as a constant value
without the need for that separate
debugging information entry."
...

I find it difficult to point to a specific answer
to the original question, but I suggest that,
taken as a whole, the standard seems
to agree with Simon Marchi: gcc's DWARF
may be valid DWARF and DW_AT_name
is a crucial element in matching things.

If things get  messy (in differences, I mean)
then DW_AT_abstract_origin can help align concrete
and abstract trees.

David Anderson

-- 
Gravity brings me down.  -- Seen on slashdot.org


From eager@eagerm.com  Wed Nov 22 23:58:47 2017
From: eager@eagerm.com (Michael Eager)
Date: Wed, 22 Nov 2017 15:58:47 -0800
Subject: [Dwarf-Discuss] Fwd: Re: DWARF: Hierarchies of abstract and
 concrete DIE instance trees
In-Reply-To: <fbb6ff0e-c254-badf-1c1d-227585b5684a@linuxmail.org>
References: <f9874b1a-4772-f67e-f92f-b81323abd21a@gmail.com>
 <fbb6ff0e-c254-badf-1c1d-227585b5684a@linuxmail.org>
Message-ID: <6b29776e-b8a2-81ff-33fe-454f87e8ddb4@eagerm.com>

On 11/22/2017 02:17 PM, David Anderson wrote:
> "In general, the structure and content of any
> given concrete inlined instance tree
> will be closely analogous to the structure
> and content of its associated abstract
> instance tree. There are a few exceptions:"
> ...
> "2. Entries in the concrete instance tree which are associated with
> entries in the
> abstract instance tree such that neither
> has a DW_AT_name attribute, and
> neither is referenced by any other debugging
> information entry, may be
> omitted. This may happen for debugging
> information entries in the abstract
> instance trees that became unnecessary
> in the concrete instance tree because
> of additional information available there.
> For example, an anonymous
> variable might have been created and
> described in the abstract instance tree,
> but because of the actual parameters
> for a particular inlined expansion, it
> could be described as a constant value
> without the need for that separate
> debugging information entry."
> ...

This says that entries in the abstract tree may be omitted from the 
concrete tree if unneeded.  I don't see this implying that entries 
(e.g., lexical blocks) may be created in the concrete tree that do not 
exist in the abstract tree.


-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From eager@eagerm.com  Tue Nov 28 18:05:43 2017
From: eager@eagerm.com (Michael Eager)
Date: Tue, 28 Nov 2017 10:05:43 -0800
Subject: [Dwarf-Discuss] Fwd: Re: Fwd: Re: DWARF: Hierarchies of abstract
 and concrete DIE instance trees
In-Reply-To: <20171128165645.GA8790@toad.ccur.com>
References: <20171128165645.GA8790@toad.ccur.com>
Message-ID: <93cfa89e-932d-267a-1022-fbdf7b3353e5@eagerm.com>

Todd seems to be having trouble posting to the mailing list.


-------- Forwarded Message --------
Subject: Re: [Dwarf-Discuss] Fwd: Re: DWARF: Hierarchies of abstract and 
concrete DIE instance trees
Date: Tue, 28 Nov 2017 09:56:45 -0700
From: Todd Allen <todd.allen@concurrent-rt.com>
Reply-To: todd.allen at concurrent-rt.com
To: Michael Eager <eager at eagerm.com>
CC: David Anderson <davea42 at linuxmail.org>, 
dwarf-discuss at lists.dwarfstd.org <dwarf-discuss at lists.dwarfstd.org>

On Wed, Nov 22, 2017 at 03:58:47PM -0800, Michael Eager wrote:
> On 11/22/2017 02:17 PM, David Anderson wrote:
> >"In general, the structure and content of any
> >given concrete inlined instance tree
> >will be closely analogous to the structure
> >and content of its associated abstract
> >instance tree. There are a few exceptions:"
> >...
> >"2. Entries in the concrete instance tree which are associated with
> >entries in the
> >abstract instance tree such that neither
> >has a DW_AT_name attribute, and
> >neither is referenced by any other debugging
> >information entry, may be
> >omitted. This may happen for debugging
> >information entries in the abstract
> >instance trees that became unnecessary
> >in the concrete instance tree because
> >of additional information available there.
> >For example, an anonymous
> >variable might have been created and
> >described in the abstract instance tree,
> >but because of the actual parameters
> >for a particular inlined expansion, it
> >could be described as a constant value
> >without the need for that separate
> >debugging information entry."
> >...
> 
> This says that entries in the abstract tree may be omitted from the
> concrete tree if unneeded.  I don't see this implying that entries
> (e.g., lexical blocks) may be created in the concrete tree that do
> not exist in the abstract tree.
> 

Well, I could bring up the whole descriptive vs. prescriptive argument to
counter that.  But I don't want to!
  I think this violates the intent of the standard, which was that the 
two trees
should match.  If that wasn't the intention, there wouldn't need to be 
wording
giving you permission to omit certain DIE's.
  The above text seems designed to ease the implementation burden in 
case, say, an
inline expansion was able to eliminate whole blocks and/or variables 
based on
knowledge of the formal arguments.  We probably could even take it 
further and
allow elimination of any DIE that (1) didn't have any new information
(attributes), and (2) wasn't necessary for hierarchical structure for 
inner DIEs
that were needed for any reason.  But that would be a whole separate
conversation.  (Honestly, I thought that was the case already.  Bad 
memory, I
guess.)
  Anyway, if you're stuck dealing with a compiler generating subtly 
wrong DWARF
like this, I sympathize.  We've been there many times too!  gcc likes to 
throw
in gratuitous lexical blocks that weren't present in the source code, 
and not
just for inline expansions.  It particularly is a shame in this case, 
because it
threw one into the concrete instance only.
  For dealing with inlines, I think the best approach for a concrete 
instance is
to create a copy of the abstract instance, and then walk the concrete 
instance
decorating it with the new information from the concrete instance.  And the
associations of DIE's should be done solely based on 
DW_AT_abstract_origin.  And
if you encounter a DIE without any DW_AT_abstract_origin, like that rogue
DW_TAG_lexical_block, I would feel free to ignore it.  Or, at least, to 
do that
conceptually.  You wouldn't necessarily have to create copies depending 
on how
you implement it.

-- 
Todd Allen
Concurrent Real-Time



From davea42@linuxmail.org  Tue Nov 28 19:37:47 2017
From: davea42@linuxmail.org (David Anderson)
Date: Tue, 28 Nov 2017 11:37:47 -0800
Subject: [Dwarf-Discuss] Fwd: Re: Fwd: Re: DWARF: Hierarchies of
 abstract and concrete DIE instance trees
In-Reply-To: <93cfa89e-932d-267a-1022-fbdf7b3353e5@eagerm.com>
References: <20171128165645.GA8790@toad.ccur.com>
 <93cfa89e-932d-267a-1022-fbdf7b3353e5@eagerm.com>
Message-ID: <1fcd7eea-8b71-439f-df54-6f09e0e407d8@linuxmail.org>

On 11/28/2017  Todd Allen wrote:
> Well,?I?could?bring?up?the?whole?descriptive?vs.?prescriptive?argument?to
> counter?that.??But?I?don't?want?to!
> ?I think this violates the intent of the standard, which was that the
> two?trees
> should match.? If that wasn't the intention, there wouldn't need to be
> wording
> giving?you?permission?to?omit?certain?DIE's.

Well, I'm happy to be wrong on this point.

Allowing  differences between concrete and
abstract other than the specified ones opens
the door to severe concrete/abstract
matching problems. Todd is right: that cannot
have been our intent in creating the standard.

Another point that perhaps should be mentioned
in Errata for DWARF5.

DavidA


-- 
Fundamentally, there may be no basis for anything. -- slashdot.org


