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