[Bug binutils/31973] Wrong length in FDE dump in readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=31973 --- Comment #1 from Vsevolod Alekseyev --- Same issue with -wF -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31973] New: Wrong length in FDE dump in readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=31973 Bug ID: 31973 Summary: Wrong length in FDE dump in readelf Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 15617 --> https://sourceware.org/bugzilla/attachment.cgi?id=15617=edit Sample binary Run the following against the attached binary: readelf -wf frames The very first FDE header line goes: 005a 0016 FDE cie=0016 pc=1474..1490 0x5a for length is wrong, the length of the first FDE record in debug_frames is 0x12, and 0x5a is the length of the associated CIE. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30880] readelf..debug-dump=loc displays bogus base addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=30880 --- Comment #7 from Vsevolod Alekseyev --- Thank you, that helps. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30880] readelf..debug-dump=loc displays bogus base addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=30880 --- Comment #5 from Vsevolod Alekseyev --- Thanks. The change to configure was intentional but wasn't meant to make it into the commit. Is there a built-in way to rebuild readelf with -O0, short of messing with the configure? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30880] readelf..debug-dump=loc displays bogus base addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=30880 --- Comment #2 from Vsevolod Alekseyev --- Created attachment 15163 --> https://sourceware.org/bugzilla/attachment.cgi?id=15163=edit Proposed fix There was another, unrelated issue with nested subprograms in the my test binary. The nested subprogram would reset the have_frame_base global to zero. Fixed that also. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30880] readelf..debug-dump=loc displays bogus base addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=30880 --- Comment #1 from Vsevolod Alekseyev --- Took a closer look. There are, essentially, three flavors of loclist dumping implemented there: - V4 (in display_loc_list()) - V5 with no offsets in unit header (in display_loclists_list()) - V5 by offsets (in display_offset_entry_loclists()) The latter is implemented naively. It doesn't take trace loclists back to CUs in debug_info and is, therefore, incapable of properly decoding DW_LLE_base_addressx, DW_LLE_startx_endx and other forms that reach back into the top DIE of the home CU. The only thing display_offset_entry_loclists() does that the other parser does not is displaying the list of entry offsets. That's a trivial fix. I'm going to get rid of display_offset_entry_loclists() altogether and make the rest output unit headers in a compatible way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #24 from Vsevolod Alekseyev --- Thanks. I'll take a look at 30880 next. On a side note - this one is marked as fixed, and 30792 is not, is that right? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #21 from Vsevolod Alekseyev --- Created attachment 15150 --> https://sourceware.org/bugzilla/attachment.cgi?id=15150=edit Proposed patch take 2 Tested against llvm-dwarfdump on the same corpus of binaries as #30880. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #10 from Vsevolod Alekseyev --- Thanks. Now that I feel reasonably comfortable around dwarf.c, I think I could tackle 29267 and 29267, and who knows what else will come up on the corpus testing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30880] New: readelf..debug-dump=loc displays bogus base addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=30880 Bug ID: 30880 Summary: readelf..debug-dump=loc displays bogus base addresses Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 15122 --> https://sourceware.org/bugzilla/attachment.cgi?id=15122=edit Test binary When dumping location lists in rnglists section with offsets in unit headers, all addresses are off. In general, it's impossible to retrieve the address range of a loclist entry without tracking a loclist to its home CU, and readelf doesn't seem to do that. Run readelf --debug-dump=loc with the attached binary. The very first loclist entry goes: 012c 0009 DW_OP_reg5 (rdi) It's an entry of type DW_LLE_offset_pair, 0 and 9 are not addresses, those are offsets from the base address in the CU's top DIE (the value of DW_AT_low_lc). The latter is not zero. Another issue exists when dumping DW_LLE_base_addressx (there is one in the loclist at 29e50). Its first value is an index into .debug_addr relative to the home CU's top DIE's DW_AT_base_addr, not relative to the section top, and yet readelf interprets it as such. As a result, the displayed value is bogus. The first one is sort of defensible, since it reflects the raw value in the entry (if not particularly useful and inconsistent with the way V4/unindexed V5 loclists are dumped), the second one is straight up bogus. Check against another parser, e. g. llvm-dwarfdump, if in doubt. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #7 from Vsevolod Alekseyev --- Anyway, here is the patch with the current state of affairs. Feel free to ditch the patch and let me know if you'd rather wait until I address the rest of 29267. Tried to keep the coding style along the current conventions, although they seem to vary within the same file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #6 from Vsevolod Alekseyev --- Created attachment 15121 --> https://sourceware.org/bugzilla/attachment.cgi?id=15121=edit Proposed patch Fixes the issue at hand and a part of 29267 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #5 from Vsevolod Alekseyev --- I think I have a workable fix. Tested on my little corpus of binaries against llvm-dwarfdump. While at it, I've fixed issue #29267 regarding rangelists, but not the loclists. Should I work on the latter, or submit a patch now? Algorithm wise, I've reused the design philosophy of V4 rangelist dumping for v5 sections. Rangelists are dumped by collecting offsets from the DW_AT_ranges attributes, sorting, and then following each into the respective debug section. I've tried to keep format changes to a minimum. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #3 from Vsevolod Alekseyev --- I don't want to change the output format gratuitously. I know for a fact people out there are parsing readelf output programmatically, as a substitute for a proper DWARF parser - that would throw them off. The V4 ranges section dumping logic works as it is, it's only V5 that's broken. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 --- Comment #1 from Vsevolod Alekseyev --- Looked at the sources - readelf straight up doesn't support rnglists sections with no offset tables (which GCC happily emits, or used to in some versions). Instead, it hard codes the offset count to 1 and dumps the first rangelist. That's way incorrect. Offset tables are a good idea in DWARFv5, but not a requirement. This logic may cause bogus output and bogue error messages, too, if a CU in the rnglists section contains *no* rangelists. Even if that was fixed in the straightforward way (unless the offset tables are present, scroll through the section top to bottom), there would be an inconsistency between the way v4 ranges section is treated and the way v5 section is treated. The problem is that of overlapping rangelists. Compilers do that. There is a rangelist in the section, pointed to by some DW_AT_ranges attribute in some DIE. Then another DW_AT_ranges points at the middle of the same rangelist. Logically, it makes sense - variable A is initialized and stays until the end of the scope, a bit later B is initialized and stays for the same scope - the area of visibility for B is a subset of that for A. The The DWARF standard doesn't prohibit that and I've seen it in the wild. This creates a problem of design philosophy: do you dump that as one rangelist, or as two? For practical debugging utility, you want two (or more), so that rangelist offsets can be followed. For faithfully representing the section contents, you want one, so that physically the same rangelist entry is not dumped several times. And readelf tries to have it both ways - for v4 sections, it treats overlapping rangelists as distinct (enumerates the rangelist offsets from DIEs and follows those), for v5 sections it dumps the section contents (incorrectly in case of no offset tables). I'd take a stab at fixing this, but please tell me which approach to enumeration is right. If consistency with past versions (i. e. the half-here, half-there approach of right now) is right, tell me that too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30781] Ranges section dump is broken if both ranges and rnglists sections are present
https://sourceware.org/bugzilla/show_bug.cgi?id=30781 --- Comment #5 from Vsevolod Alekseyev --- Found a similar but distinct bug on a v5 only binary, https://sourceware.org/bugzilla/show_bug.cgi?id=30792 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] New: Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 Bug ID: 30792 Summary: Rnglists section dump in readelf outputs one rangelist per CU Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 15082 --> https://sourceware.org/bugzilla/attachment.cgi?id=15082=edit dwarf_v5ops.so.zip Followup from #30781. Run the following with the attached binary: readelf --debug-dump=Ranges dwarf_v5ops.so.elf For the first CU in the rnglists section it outputs the range list at 0xc and moves on to the next CU. Meanwhile, there is a lot of perfectly valid rangelists remaining in the first CU. To name one, the rangelist at 0x1c is referenced by the DIE at 0x6afb (DW_TAG_inlined_subroutine inside of DW_TAG_subroutine for JiPad_AddPoint). The next rnglists-CU at 0x142 also lists only one rangelist. So does 0x10329, 0x103f1, and 0x105e9. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30781] Ranges section dump is broken if both ranges and rnglists sections are present
https://sourceware.org/bugzilla/show_bug.cgi?id=30781 --- Comment #3 from Vsevolod Alekseyev --- This particular issue (bogus lists found in v4- rangelists when v4- and v5 coexist) is definitely addressed by the patch. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30781] New: Ranges section dump is broken if both ranges and rnglists sections are present
https://sourceware.org/bugzilla/show_bug.cgi?id=30781 Bug ID: 30781 Summary: Ranges section dump is broken if both ranges and rnglists sections are present Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 15071 --> https://sourceware.org/bugzilla/attachment.cgi?id=15071=edit dwarf_test_versions_mix.elf Run the following with the attached binary: readelf --debug-dump=Ranges dwarf_test_versions_mix.elf For the .debug_ranges section, it outputs the following: Offset BeginEnd 1040 1060 000c readelf: Warning: Corrupt offset (0x2d) in range entry 2 That's wrong, there is only one rangelist in that section, at 0. The error stems from the way readelf enumerates rangelists - it scrolls through all DIEs in the binary and picks the value of DW_AT_ranges. In case of a split v4/v5 binary, like this one, the logic of enumeration should be version aware; when looking at a DIE, it should check whether the DIE in a DWARFv5 CU or in a DWARFv4- one; the rangelist offsets in the former point at .debug_rnglists section, not at the .debug_ranges one. Specifically for this binary, the bogus rangelist offsets 0xc and 0x2d come DIEs in the CUs for crti.S and crtn.S, which are both DWARFv5. Chances are, dumping debug_rnglists is affected by the same issue, and a parallel issue plagues the loclist sections dump; the loclists sections for DWARF v4- and for DWARFv5 may also coexist in the same binary. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #20 from Vsevolod Alekseyev --- At this juncture, we gave up on using readelf as a reference implementation of DWARF parsing. You may do with this issue as you please. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #18 from Vsevolod Alekseyev --- Same story in rnglists. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #17 from Vsevolod Alekseyev --- The loclist entries in sections with nonblank offset tables in are dumped differently; the start/end address of location entries is not resolved relative to the corresponding CU's base PC. This is inconsistent with the past behavior, and rather misleading. Didn't check the rangelists yet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #16 from Vsevolod Alekseyev --- I see you've changed the output format. That will take some time to catch up. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #13 from Vsevolod Alekseyev --- Cite: http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-June/004928.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #12 from Vsevolod Alekseyev --- It's not as bad; a gentleman at the DWARF mailing list pointed out there was a rule in section 7.4 near the end, that the bitness of the same CU's contributions in different sections should be the same: "The 32-bit and 64-bit DWARF format conventions must not be intermixed within a single compilation unit." So reusing the bitness from the corresponding CU in the debug_info is a proper and correct thing to do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #10 from Vsevolod Alekseyev --- 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 0x 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.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #9 from Vsevolod Alekseyev --- The patches are supposed to be cumulative, right? And the first one is already not in the bug? So there is no way to apply them on top of HEAD anymore, unless I've saved all three? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #8 from Vsevolod Alekseyev --- The warnings that "readelf --debug-dump=info" is giving on that binary are all bogus; they all have to do with readelf looking for the offset in the wrong place. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #7 from Vsevolod Alekseyev --- Created attachment 14162 --> https://sourceware.org/bugzilla/attachment.cgi?id=14162=edit Test binary Have a test binary. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #4 from Vsevolod Alekseyev --- Even declared as "dwarf_vma index", the numbers are all wrong. Looks like fetch_indexed_value is not taking into account the DW_AT_loclists_base/DW_AT_rnglists_base attribute value, which stores the address of the offset table of the current compile unit's contribution in debug_loclists/debug_rnglists, respectively. Similar issue here: #29266. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #3 from Vsevolod Alekseyev --- Comment on attachment 14159 --> https://sourceware.org/bugzilla/attachment.cgi?id=14159 Proposed Patch Does not compile, "index" is not declared. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29270] Signed integer overflow with DW_FORM_udata
https://sourceware.org/bugzilla/show_bug.cgi?id=29270 --- Comment #3 from Vsevolod Alekseyev --- Confirmed, thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #1 from Vsevolod Alekseyev --- The culprit is, probably, the case statement at dwarf.c:2774, where fetch_indexed_addr() is being called both for DW_FORM_addrxN (where it belongs) and for DW_FORM_loclistx/DW_FORM_rnglistx (where it does not). For the latter, fetch_indexed_value should be used instead. The text description is off, too. The loclistx value doesn't represent an address index. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29268] readelf misinterprets register rule inheritance from CIE to FDE
https://sourceware.org/bugzilla/show_bug.cgi?id=29268 Vsevolod Alekseyev changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Vsevolod Alekseyev --- Oops, duplicate of 29250, sorry. *** This bug has been marked as a duplicate of bug 29250 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29250] readelf erases CIE initial register state
https://sourceware.org/bugzilla/show_bug.cgi?id=29250 Vsevolod Alekseyev changed: What|Removed |Added CC||sevaa at sprynet dot com --- Comment #5 from Vsevolod Alekseyev --- *** Bug 29268 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29270] New: Signed integer overflow with DW_FORM_udata
https://sourceware.org/bugzilla/show_bug.cgi?id=29270 Bug ID: 29270 Summary: Signed integer overflow with DW_FORM_udata Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14155 --> https://sourceware.org/bugzilla/attachment.cgi?id=14155=edit Test binary and source Consider the debug info in the attached binary. If you execute "readelf --debug-dump udata", you'll see the following line: <2f> DW_AT_const_value : -9223372036854775808 The form of that attribute is DW_FORM_udata. It's unsigned and positive, the minus is bogus. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] New: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Bug ID: 29267 Summary: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- When readelf --debug-dump=info prints attributes of type DW_FORM_loclistx, DW_FORM_rnglistx, it prints what should be the offset of the loclist/rangelist in the respective section. The raw value of this attribute is supposed to be an index into the offsets table in the compilation unit header inside the debug_loclists or debug_rnglists sections, respectively, while the address of the offset table itself should be taken from the DW_AT_loclists_base or DW_AT_rnglists_base, respecively, in the CU's top DIE. But it looks like readelf looks up the offset in the debug_addr section, instead of debug_loclists/debug_rnglists section. This even causes warnings of type "Offset into section .debug_addr too big:", because the offset was never meant to be in .debug_addr. I've got a repro for that from clang++-11, but it's big. I'll try to find a smaller one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29266] readelf ..info misreports DW_FORM_strxN
https://sourceware.org/bugzilla/show_bug.cgi?id=29266 --- Comment #1 from Vsevolod Alekseyev --- Additional info: when parsing the attribute at offset 0x54, the first strx one in the second CU, and fetch_indexed_string is invoked, the value of the this_set parameter, which I believe is supposed to point at the CU header within debug_str_offsets, is still 0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29268] New: readelf misinterprets register rule inheritance from CIE to FDE
https://sourceware.org/bugzilla/show_bug.cgi?id=29268 Bug ID: 29268 Summary: readelf misinterprets register rule inheritance from CIE to FDE Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14154 --> https://sourceware.org/bugzilla/attachment.cgi?id=14154=edit Test binary Consider the debug info attached binary. The binary's first FDE in .eh_frame has initial_location 0x1060, and the following instructions: DW_CFA_advance_loc 4# Move PC by 4 DW_CFA_undefined 16 # Change the rule for R16 to undefined The linked CIE marks R16 as the return address, and has the following instructions: DW_CFA_def_cfa 7, 8# CFA is at R7+8 DW_CFA_offset 16, 1# Set the rule for R16 to [CFA+1*data_aligment_factor]) The GNU readelf, if executed with --debug-dump=frames-interp, dumps the FDE as follows: 0018 0014 001c FDE cie= pc=1060..1086 LOC CFA ra 1060 rsp+8u 1064 rsp+8u Meanwhile, an alternative parser thinks that at the range [0x1060-0x1064), the rule for RA/R16 should be as inherited from the CIE, and it goes c-8. I've debugged readelf (the latest master, as of 06/01/22), to that point. There are two passes over the FDE instructions: one starting on dwarf.c:9296, the other starting at dwarf.c:9442. On the first pass, when DW_CFA_undefined is encountered, there is the following case statement: READ_ULEB (reg, start, block_end); if (frame_need_space (fc, reg) >= 0) fc->col_type[reg] = DW_CFA_undefined; break; If I understand correctly, the intended purpose of the first pass is to allocate enough memory in the fc->col_type and fc->col_offset arrays, and the logic of this operator's handling was meant to be: if this register was not mentioned before, allocate space for it, and reset its rule to undefined. HOWEVER, if the register WAS mentioned before (e. g. in the CIE), frame_need_space() returns 0, and the if() body executes anyway, and resets the rule for the register to undefined, erasing the initial state as specified by the CIE. I think the if statement should go, instead, "if (frame_need_space (fc, reg) > 0)". Same for other register-rule-type operators on the first pass. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29266] New: readelf ..info misreports DW_FORM_strxN
https://sourceware.org/bugzilla/show_bug.cgi?id=29266 Bug ID: 29266 Summary: readelf ..info misreports DW_FORM_strxN Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14153 --> https://sourceware.org/bugzilla/attachment.cgi?id=14153=edit Test binary and sources Consider the debug information in the attached binary. It consists of two compilation units - foo.cpp and bar.cpp. Run "readelf --debug-dump=info foo" with the latest master as of 2022-06-20. It reports the value of DW_AT_name as "foo.cpp" for both compilation units. That can't be right. Internally, it looks as if the logic of resolving DW_FORM_strx, DW_FORM_strx1..4 form attributes looks into the portion of the debug_str_offsets section that pertains to the top CU as opposed to the current CU. Elsewhere, it also causes numerous bogus warnings like "DW_FORM_GNU_str_index offset too big: 0x1350 vs 0xbf0", where the str_offset count in the current CU is greater than that in the top CU. -- You are receiving this mail because: You are on the CC list for the bug.
