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

[Michael Eager]

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