https://sourceware.org/bugzilla/show_bug.cgi?id=29267
--- Comment #10 from Vsevolod Alekseyev <sevaa at sprynet dot com> --- There is a bit of parsing complication here that I don't think the current parser quite appreciates. The DWARF bitness may vary between CUs in indexed sections, and short of going through the headers, linked list style, there is no way to determine the bitness for any given section from the DIE data. The structure of debug_loclists goes like this: CU_header_0: length AKA bitness indicator (4 or 12) version (2) address_size (1) selector_size (1) offset_entry_count (4) offsets[0] (4 or 8) <-- DW_AT_loclists_base points here offsets[1] (4 or 8) ...more offsets ...the actual loclists The offsets table contain the offsets of the target loclists, relative to the offsets table start. The size of the offset (4 or 8) is determined by the length field in the header, the usual DWARF style. Now, from the value of DW_AT_loclists_base alone, it's pretty much impossible to tell whether the section is 32- or 64-bit DWARF (except for the 0th CU, where the DW_AT_loclists_base can be either 12 or 20). In subsequent CUs, you can't seek back from the offset table to the top of header, because it's variable length. If you look at the dword at DW_AT_loclists_base-20, it may be 0xffffffff by pure accident. Similar situation in debug_rnglists, debug_addr, debug_str_offsets. A proper parser should go through all CU headers in the section (you can sort of fast-forward through them by skipping by length), determine and store the bitness of each, and then recover the bitness of any particular CU by matching the DW_AT_rnglists_base against that. One *slightly* better alternative would be - reuse the bitness from the corresponding CU in the debug_info. While it is possible to compose a correct DWARF dataset where the bitness between contributions from the same compile unit in different section varies, it would be a pain in the neck for the compiler vendor. Or you can just assume 32 bits. The spec encourages the implementors not to use 64-bit DWARF unless absolutely necessary. How often does one see 4GB+ sections in a binary? -- You are receiving this mail because: You are on the CC list for the bug.
