[llvm-dev] [DebugInfo] Different representations of optimised-out variables in DWARF

[David Blaikie via llvm-dev]

On Thu, Jan 28, 2021 at 7:52 AM Jeremy Morse <jeremy.morse.llvm at gmail.com>
wrote:

> Hi,
>
> David wrote:
> > We should never produce DWARF like this:
>
> A patch to achieve that: https://reviews.llvm.org/D95617
>
> On Thu, Jan 28, 2021 at 10:19 AM Djordje Todorovic
> <Djordje.Todorovic at syrmia.com> wrote:
> > IMPO, this works intuitively, but if you think that we should handle 2)
> case in some other way (e.g. just to ignore such parameter), please let me
> know.
>
> As far as I understand it, we shouldn't be counting the number of
> variables "processed", and instead be counting:
>  * The total number of variables for each scope, by using the inlined
> subprograms abstract origins to find in-scope variables that have no
> location,
>  * The number of concrete variables that have a DW_AT_location
>
> The first number should remain stable regardless of how well we do at
> tracking variable locations.
>

Yep, +1 to that.

Said another way, the presence or absence of an inline
variable/formal_parameter with only an abstract_origin should not change
the answer. And more specifically, the coverage shouldn't go /down/ when we
add a single byte of location information to a variable that was previously
uncovered. That variable having no coverage should already be recorded in
the stats (which it isn't currently, as I understand it). To do this, as
Jeremy said - we should go searching for variables in the abstract DIE
tree, even if they don't appear in the inlined tree.

(I'm /vaguely/ remembering some particular issue with matching up inlined
scope entities to their abstract origin... maybe something about inlined
scopes that needed to be emitted/had entities in them even when they were
zero length or something... but I can't quite recall right now. Oh well)

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210128/b9261e80/attachment.html>