https://sourceware.org/bugzilla/show_bug.cgi?id=31975
--- Comment #1 from Vsevolod Alekseyev ---
This is specific to the forward reference situation.
The parse loop over the CIE operations (dwarf.c:9765) doesn't get a chance to
run until the CIE becomes the current chunk while parsing the sectio
https://sourceware.org/bugzilla/show_bug.cgi?id=31973
--- Comment #2 from Vsevolod Alekseyev ---
Created attachment 15619
--> https://sourceware.org/bugzilla/attachment.cgi?id=15619&action=edit
Proposed fix
The same variable was used for the FDE length and, if the CIE was ahead of FDE
and not
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: sevaa at sprynet dot com
Target Milestone: ---
See the binary in #31973. If you run
readelf -wF frames
the dump for the very first FDE doesn't list the rules for registers r0 to
r271, even though the
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.
: 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&action=edit
Sample binary
Run the following against the attached
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.
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 rece
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&action=edit
Proposed fix
There was another, unrelated issue with nested subprograms in the my test
binary. The
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 b
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.
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&action=edit
Proposed patch take 2
Tested against llvm-dwarfdump on the same corpus of binaries as #30880.
--
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 bec
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&action=edit
Test binary
When dumping location l
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
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&action=edit
Proposed patch
Fixes the issue at hand and a part of 29267
--
You are receiving this mail because:
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 latt
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
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
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.
: 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&action=edit
dwarf_v5ops
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 fo
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&acti
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 lis
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.
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 in
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.
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.
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 sa
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
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 receiv
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 becau
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&action=edit
Test binary
Have a test binary.
--
You are receiving this mail because:
You are on the CC list for
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
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 o
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.
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
https://sourceware.org/bugzilla/show_bug.cgi?id=29268
Vsevolod Alekseyev changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNC
https://sourceware.org/bugzilla/show_bug.cgi?id=29250
Vsevolod Alekseyev changed:
What|Removed |Added
CC||sevaa at sprynet dot com
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&action=edit
Test binary and source
Consider the debug info
: 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
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 t
: 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&action=edit
Test
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&action=edit
Test binary and sources
Consider the debug information
43 matches
Mail list logo
