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 <dave...@gmail.com> To: dwarf-discuss@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 _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
