[Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

David Blaikie dblaikie@gmail.com
Thu Mar 11 21:27:38 GMT 2021


On Thu, Mar 11, 2021 at 12:07 PM Mark Wielaard <mark at klomp.org> wrote:

> Hi David,
>
> On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote:
> > > > (I went to look a bit further and GCC's .debug_loclists.dwo but it
> seems
> > > > there's something about it that llvm-dwarfdump can't understand - it
> only
> > > > prints a handful of rather mangled location lists... not sure which
> > > > component (GCC, llvm-dwarfdump, or both) is getting things confused
> here
> > > -
> > > > oh, maybe some kind of DWARF extension for the "views" system, by the
> > > looks
> > > > of it)
> > >
> > > Yes, you might try -gno-variable-location-views or simply use binutils
> or
> > > elfutils readelf to look at them.
> > >
> >
> > Thanks! - is this proposed as a DWARF extension? I thought I remembered
> it
> > coming up, but hadn't realized how non-standard it was/that it was
> already
> > implemented. (quick search on the issues page and I can't find any
> mention
> > of it at least)
>
> We kind of need a dwarf-extensions discussion list to document/discuss
> these kind of non-extendable DWARF extensions. Only half kidding. Some
> things in DWARF are well designed to allow vendor extensions that can
> be skipped/ignored, but some aren't and we probably need to coordinate
> more because it is years between standard spec releases.
>

Yeah, happy to do that anywhere - dwarf-discuss is probably OK for it, I'd
guess.

& happy to co-implement DWARF extensions/future proposals - especially when
they're carving out an extension space, so it's less a question of "is this
a good extension" (a more nuanced/difficult debate - then it comes down to
is anyone going to use it/need it in lldb, etc) and more "is it reasonable
for this feature to be extensible and how should that work". Won't mean
immediate implementation in LLVM, but at least agreeing on the direction &
will make adding support at least in dumpers more clearly
motivated/understood/etc.

Implementing not-yet-standardized things, especially if they look like a
plausible direction for the standard, is a good thing - getting some
implementation experience, ironing out any gotchas, etc, before it's
published and possibly more widely adopted. (that said, I wouldn't mind
knowing what "widely adopted" looks like - folks mention maintaining old or
obscure toolchains, but not sure if they're using more modern DWARF, or is
it basically Clang, LLDB, GCC, and GDB using anything like DWARFv5 and
beyond?)


> Extending loclists is a bit of a pain because they aren't really
> extendable. Making them extendable is
> http://dwarfstd.org/ShowIssue.php?issue=170427.2


Ah, indeed - thanks for the link!


> but I am still
> pondering whether that really helps here because as written you can
> only interpret them end of list, but not really skip them.
>

Yeah, it would be nice if extension opcodes had a uleb length as their
first argument.

(this is essentially the difference between a custom DW_TAG or DW_AT (very
cheap, easy for consumers to ignore if they don't recognize it) and a
custom DW_FORM (expensive - consumer can't parse the list at all) - though
I guess this extension issue /might/ fall in between, as you could read the
list up until you hit an extension, and use that partial information for
locations, even if you couldn't parse all of it)


> Location views themselves are
> http://dwarfstd.org/ShowIssue.php?issue=170427.1


Right right - thanks for that!


> Alexandre Oliva, who proposed the Location Views as DWARF
> extension. He has some more background material at
> http://www.fsfla.org/~lxoliva/papers/sfn/ Which is mostly on variable
> tracking assignments and statement frontier annotations.  Which
> describes the GCC implementation that makes it possible to have
> location views.
>
> What is proposed is slightly different from what GCC currently
> implements though. Caroline, Cary and I are supposed to sit down and
> discuss it to see how it can be standardized. But finding time has
> been tricky.
>

*nod* takes some time, I'm interested to see how it comes along.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210311/bbe4905e/attachment.html>



More information about the Dwarf-discuss mailing list