[Dwarf-Discuss] DWARF bitness in loclists, etc

[David Blaikie]

On Sun, Jun 26, 2022 at 2:24 PM Vsevolod Alekseyev via Dwarf-Discuss
<dwarf-discuss at lists.dwarfstd.org> wrote:
>
> Makes sense, thank you. It's enough for me to go with as far as parsing is concerned.
>
> That said, why bother with the bitness indicator in the ...lists sections at all? I can't imagine parsing them from top to bottom; debugger-type applications normally look up loclists based on DIE data, and a DIE implicitly carries a CU context in it already, bitness and all. Even "dump all loclists" applications (e. g. readelf) don't go by scrolling through the loclists section; it may contain gaps and objects other than loclists (e. g. locview pairs; it's a GNU extension), and is not generally parseable without looking at the DIEs anyway.
>
> As for rangelists, they may overlap. I have binaries to show.
>
> Bottom line, for dumping loc/rnglists one starts by enumerating DIEs, and once you do that, you have enough context to tell the bitness without looking at the CU in loclists header at all.

I can say that llvm-dwarfdump, for instance, does support/work by
dumping sections directly, not only the parts of them referenced from
CUs. Nice to have the headers so you can look at them in isolation -
but, yeah, it does fall down if there are gaps/garbage in between
valid contributions to a section, or those locview GNU extensions.

Before DWARFv5, generally what you're saying is how it works - most
sections didn't have headers, or not adequate headers (eg: debug_line
was missing some things like the bitness, I think? or maybe some other
properties - address size, perhaps) but in DWARFv5 they're mostly
complete (few gaps, like I think .debug_macinfo (or .debug_macro,
whichever one is the new one) doesn't start with a size, but does
encode the 32/64 as a flag - it'd be nicer if it used a length like
everything else, would make it easier to skip unknown version data,
etc)

> -----Original Message-----
> From: Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org> On Behalf Of David Anderson via Dwarf-Discuss
> Sent: Sunday, June 26, 2022 11:39 AM
> To: dwarf-discuss at lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] DWARF bitness in loclists, etc
>
> On 6/26/22 05:52, Vsevolod Alekseyev via Dwarf-Discuss wrote:
> > Greetings,
> >
> > I?m involved with a Python DWARF parser, Pyelftools (
> > https://github.com/eliben/pyelftools/
> > <https://github.com/eliben/pyelftools/> ). I have a question about
> > DWARF5 and the newly indexed loclists/rnglists sections, please.
> >
> > In those sections, each CU gets a block. The block starts with a
> > header, which starts with a 4/12 byte unit_length field, which also
> > serves as a bitness indicator (32/64) ? right? So the size of the
> > offset values in the offset table below the header is driven by the
> > structure of unit_length. The DWARF5 standard, section 7.29 talks
> > about ?32-bit DWARF? and ?64-bit DWARF? without making clear which of
> > the bitness indicators should be used ? the one from the original
> > DIE?s CU, or the one from the CU header loclists where the DIE points.
> > I was presuming all along that it?s latter; can someone please confirm? Thank you.
>
> The 32/64 indicator is what the standard calls  lengths and offset sizes.  DWARF5 Section 7.4.
>
> The intent was always that all content related to a single CU (whether in one section or more than one, as in your question) have the SAME
> offset size.    Meaning either place one looks at the 32/64 offset size
> related to a CU it must match the CU header offset size.
>
> Unfortunately DWARF3-DWARF5 do not clearly say this.
> I'm likely not saying it clearly...sigh.
> (DWARF2 did not allow for a 64bit offset/length size).
>
> If the offset sizes related to a single CU in sections like loclists/rngslists do not match the CU offset size the DWARF is corrupt.
>
> An elf file could have  one CU with 32 and another CU with 64 bit offset size mixed into a single object file.  Each with its associated loclists/rnglists (etc) with the offset size of its CU.
> This possibility too was always intended (starting with DWARF3).
>
> Corrections/clarifications are welcome.
>
> Hope this makes sense.
> David Anderson
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org