llvm dev - Oct 2019 - DebugInfo work contribution and update.

On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <paul.robinson at sony.com>
wrote:
> > From: David Blaikie <dblaikie at gmail.com>
> >> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto:
> paul.robinson at sony.com> wrote:
> >> There are many bits of DWARF-5 that haven’t been implemented.
> >
> > Got a short list, by chance?
>
> I can't say I've been keeping track of all that has gone in, but
based
> on the list that I came up with when I was sizing the initial DWARF 5
> work, things that might not be done include:
>
> Default location entry
> Inline namespace attribute
> Reference-qualified member functions
> "auto" return type
> Type/item alignment
> Defaulted template parameter
> Atomic type modifier
> DW_OP_implicit_pointer
> .debug_macro section
> Typed expressions
> Supplementary objects
>
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)

>
> Things I have noticed going in recently:
>
> Call-site and entry-value stuff (is that complete?)
> New language/dialect codes
> Deleted/defaulted members is in progress
> "noreturn" functions is in progress
>
> I can't remember whether split-DWARF is fully v5 compliant...
>
> If any items above are in fact done, my apologies and VERY happy to be
> corrected.
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191010/35519f98/attachment.html>

> 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.
--paulr

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>