[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nick Clifton --- Patch applied. -- 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/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last reconfirmed||2023-09-25 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #9 from Nick Clifton --- (In reply to Vsevolod Alekseyev from comment #7) > 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. No I liked it, so I have gone ahead and checked it in. There were a few minor formatting issues, but I cleaned those up. -- 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 #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84102ebc29a1ea531e7fe78bd841bfb2fe501dc2 commit 84102ebc29a1ea531e7fe78bd841bfb2fe501dc2 Author: Vsevolod Alekseyev Date: Mon Sep 25 18:01:31 2023 +0100 Fix readelf's display of dwarf v5 range lists PR 30792 * dwarf.h (struct debug_info): Remove range_versions field. * dwarf.c (fetch_indexed_offset): New function. (read_and_display_attr_value): Use it for DW_FORM_rnglistx. Remove code to initialise range_versions. (skip_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (process_debug_info): Call read_bases. (display_debug_rnglists): Rename to display_debug_rnglists_unit_header and only display the range list header information. (display_debug_ranges): Adjust. -- 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 #4 from Nick Clifton --- (In reply to Vsevolod Alekseyev from comment #3) > 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. Right - so for the v5 output, first make sure that it is correct and accurate. Then, if possible, emulate the v4 output, so that users do not become confused between v4 and v5. -- 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 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to Vsevolod Alekseyev from comment #1) Hi Vsevolod, > 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, Thank you! :-) > 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. There is no one way that is "right", but my advice is this: readelf is primarily intended to be tool to assist in diagnosing problems with the low level features of ELF format binary files. Hence an output that assists in debugging is preferable to one that goes for accuracy over helpfulness. That said, the best solution would be one that caters for both camps. For example if the output showed the range lists only once, but also pointed out which parts of each list were associated with specific DIEs, then this would be even more helpful. It would let the user know that the lists were being used multiple times, and hence, by inference, that there are entities which share the same range information and might therefore be related in other ways as well. Cheers Nick -- 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.
