[Dwarf-Discuss] Fwd: Re: Fwd: Re: DWARF: Hierarchies of abstract and concrete DIE instance trees
eager at eagerm.com
Tue Nov 28 10:05:43 PST 2017
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 at 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
should match. If that wasn't the intention, there wouldn't need to be
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
knowledge of the formal arguments. We probably could even take it
allow elimination of any DIE that (1) didn't have any new information
(attributes), and (2) wasn't necessary for hierarchical structure for
that were needed for any reason. But that would be a whole separate
conversation. (Honestly, I thought that was the case already. Bad
Anyway, if you're stuck dealing with a compiler generating subtly
like this, I sympathize. We've been there many times too! gcc likes to
in gratuitous lexical blocks that weren't present in the source code,
just for inline expansions. It particularly is a shame in this case,
threw one into the concrete instance only.
For dealing with inlines, I think the best approach for a concrete
to create a copy of the abstract instance, and then walk the concrete
decorating it with the new information from the concrete instance. And the
associations of DIE's should be done solely based on
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
conceptually. You wouldn't necessarily have to create copies depending
you implement it.
More information about the Dwarf-Discuss