[Dwarf-Discuss] Fwd: Re: DWARF: Hierarchies of abstract and concrete DIE instance trees

[David Anderson]

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