On Sun, Jun 26, 2022 at 2:24 PM Vsevolod Alekseyev via Dwarf-Discuss <dwarf-discuss@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-boun...@lists.dwarfstd.org> On Behalf Of > David Anderson via Dwarf-Discuss > Sent: Sunday, June 26, 2022 11:39 AM > To: dwarf-discuss@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@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
