[llvm-dev] [DebugInfo] The current status of debug values using multiple machine locations

[David Blaikie via llvm-dev]

On Tue, Jan 26, 2021 at 12:10 PM <stephen.tozer at sony.com> wrote:

> > when you say "more variables being emitted to DWARF with 0% coverage" -
> what do you mean by that? Are we counting a variable with no location
> attribute as being 100% covered, because it isn't partially covered? Could
> we instead count such variables as 0% covered?
>
> Not exactly, it's that we aren't considering them at all. If we have 2
> variables a and b with 100% and 50% coverage respectively, we'd have 75%
> total coverage (assuming they both occupy identically sized scopes). If a
> new optimization causes us to drop b's coverage to 0%, then we would
> expect the overall coverage to drop to 50%. However, we may end up dropping
> b entirely from the DWARF,
>

When does this ^ happen? In optimized builds we include all local variables
in a "variables" attachment to the DISubprogram, so we shouldn't be losing
variables entirely.


> in which case the dwarfdump statistics see that we only have 1 variable
> and it has 100% coverage, giving us 100% overall coverage. While it would
> be accurate to count these missing variables as 0% covered, if there's no
> mention of them in the DWARF then there is no way for dwarfdump to know
> they exist.
>
> I'm not actually sure what causes variables to be dropped from the DWARF
> entirely, as opposed to them existing but having an unknown location for
> their entire scope; however, outside of our desire to use dwarfdump to
> analyze our debug info it's simply more efficient to omit variables with no
> location, since they inflate the debug info size and I don't believe
> there's any practical value in having them.
>

I think it's pretty important that we keep them. It helps a user understand
that they've not mistyped the name of a variable, etc - that it's there,
but has no location is distinct from it not being there at all. A marginal
motivation is that this can also produce even more surprising behavior in
the case of shadowing - if a shadowing variable is omitted entirely, when
the user tries to print it they might get the shadowed variable and mistake
it for the shadowing one. Admittedly DWARF doesn't make much of an effort
to be reproduce shadowing perfectly - functions and other entities that are
never referenced are generally omitted and can produce this kind of
shadowing/incorrect lookup behavior - so it's a marginal motivation.

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