[llvm] r362951 - [DebugInfo] Terminate all location-lists at end of block

[David Blaikie via llvm-commits]

On Fri, Jun 21, 2019 at 4:58 AM <paul.robinson at sony.com> wrote:

> > Is it worth turning these cases into a `llvm-dwarfdump -verify` error?
> > (Or some kind of warning?). They look relatively straightforwards to
> > identify, aren't contributing to the debug experience, but are costing
> > space. I'm all for eliminating these quirks, it bothers users for
> > nothing.
> >
> > (I'm not familiar with `llvm-dwarfdump -verfy`, perhaps this is more a
> > case of "debuginfo isn't helpful" as opposed to "the DWARF is wrong").
>
> The DWARF spec (AFAICT) never specifically constrains the addresses in
> a location list to be within the range of the object it's attached to.
> I do think this is kind of assumed in at least one place though, and
> arguably it wouldn't mean anything. (I'm assuming things like landing
> pads for exception handling to destroy objects will DTRT WRT the object
> range.)
>
> `-verify` currently looks at the ranges on an object, and validates the
> location expressions, but does not validate the ranges in the location
> list against the ranges on the object.  That seems like a reasonable
> thing to check.
>

In some ways I'd sort of like to allow this ^ when it doesn't hurt (when
it's not a case of "oh, you should've just used a single location
description" or "this range covers two discontiguous chunks of the
enclosing scope's ranges - so it's more compact this way") for the
potential size benefit. Though admittedly, it wouldn't hurt to have data on
how often this happens/how much the savings are once the related bugs are
fixed.


>
>                       |
> It could also conceivably look for contiguous ranges with the same
> expression. Even if you take the position that it's not "illegal DWARF"
> (which it really isn't, it's just taking up more bytes than necessary)
> it's certainly not the kind of thing we want to be emitting and would
> be evidence of a bug/missing-feature in buildLocationList.
>

*nod* That's the one that's pretty clearly without benefit/pure inefficient
representation.


>
> --paulr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190621/6c7963de/attachment.html>