[llvm-dev] DebugInfo work contribution and update.

[David Blaikie via llvm-dev]

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com>
wrote:

> > Ah, thanks for the list - mostly I'm interested in cases where Clang's
> > output is not valid DWARFv5 when requested - the new features DWARFv5
> > enables/allows but doesn't require are lower priority to me. Which I
> > don't think too much is left - DWARFv5 loclists in split DWARF is one
> > I know of & might get to if someone else doesn't do it before me - I'm
> > currently improving loclist emission (quality of implementation - using
> > fewer address pool entries & just general code cleanup to share some of
> > teh implementation with rnglist emission, not a compliance issue)
>
> You might want to look at default location entry then; particularly if a
> variable moves around but has a stack home, it can reduce the number of
> entries and maybe eliminate some .debug_addr references.
>

I don't think it'd reduce debug_addr references - I'm setting it up to only
use the base address of the function start and everything's offset pairs
from there, so loclists shouldn't create any addr entries, only using
existing ones needed for the function's low_pc/CU's ranges, etc.

I don't know what our current variable location tracking would ever likely
manage to preserve the location information enough for it to cover the
whole scope (or at least not often) & then pick a default location as the
most common used location across that scope. (I'm guessing almost any
optimizations will cause some part of the address range of the enclosing
scope to lose locations).

If we do actually hit that case (probably would be worth building a DWARF
statistic (even a temporary one) that tests whether a location list
describes the entire address range of the enclosing scope - I'm guessing
that happens roughly never at the moment) we could look into improving the
DWARF emission to be more compact by using the default.

- Dave


> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191010/9dc1e31d/attachment.html>