https://sourceware.org/bugzilla/show_bug.cgi?id=28459
Bug ID: 28459
Summary: Readelf issues bogus warning
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jeffreyalaw at gmail dot com
Target Milestone: ---
Created attachment 13723
--> https://sourceware.org/bugzilla/attachment.cgi?id=13723&action=edit
Testcase, x86 binary
This change from Alan added some sanity checking to the dwarf reader. This
probably a good thing, but I suspect it's got a buglet:
commit b4951546078b869ce2f720561a2c59cfe2d005c9
Author: Alan Modra <[email protected]>
Date: Sat May 15 15:17:58 2021 +0930
display_debug_ranges
* dwarf.c (display_debug_ranges): Delete initial_length_size.
Correct fallback size calculated on finding a reloc. Constrain
data reads to length given in header. Avoid pointer UB.
Run readelf -w on the attached file using a trunk version of readelf. It'll
report an error like this:
Contents of the .debug_rnglists section:
Offset Begin End
0000000c 0000000000401000 0000000000401012
00000016 00000000004011d8 00000000004011dc
00000020 <End of list>
readelf: Warning: Corrupt offset (0x0000002d) in range entry 1
Whereas older versions as well as "objdump -W" would report:
Contents of the .debug_rnglists section:
Offset Begin End
0000000c 0000000000401000 0000000000401012
00000016 00000000004011d8 00000000004011dc
00000020 <End of list>
0000002d 0000000000401040 0000000000401055
00000037 <End of list>
You may recognize this as a subset of the compress.exp tests from the ld
testsuite and it is. Of course normally those binaries don't have
debug_rnglists. But somehow in our internal builds "-O2" is getting passed
down into the ld tests. That creates a .debug_rnglist for main.o in the test.
That alone is insufficient to trigger the problem. We also have our crt*
files from glibc with debugging symbols, so those also have .debug_rnglist
sections. The combination of having those two input objects with
.debug_rnglist sections linked together into an executable is what ultimately
triggers the failure.
I haven't debugged the logic of the change.
--
You are receiving this mail because:
You are on the CC list for the bug.
