https://sourceware.org/bugzilla/show_bug.cgi?id=32809
Bug ID: 32809
Summary: readelf doesn't dump .debug_loclists section correctly
for 64-bit target and mixed dwarf4/5 content
Product: binutils
Version: 2.45 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: lynda.rowe at ericsson dot com
Target Milestone: ---
Readelf seems to get stuck in an infinite loop or erroneously dumps too much
content for .debug_loclists section when a mix of dwarf4 and dwarf5 is used on
x86 64-bit. An example that demonstrates this is:
dwarf4.c:
extern void bar();
void foo(int p) {
int local = p;
bar();
local = 123;
bar();
local = 456;
}
dwarf5.c:
extern void foo(int);
void bar() {
}
int global;
int main() {
int local = global;
foo(1);
local = 123;
foo(2);
local = 456;
return 0;
}
Building this on:
$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: RedHatEnterprise
Description: Red Hat Enterprise Linux release 8.10 (Ootpa)
Release: 8.10
Codename: Ootpa
With clang:
$ clang --version
clang version 20.1.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
Build config: +assertions
rm -f dwarf4.o dwarf5.o && clang -c -g -O1 -gdwarf-4 -o dwarf4.o dwarf4.c &&
clang -c -g -O1 -gdwarf-5 -o dwarf5.o dwarf5.c && clang dwarf4.o dwarf5.o -o
a.out
I built binutils on the following commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=dad0da34b7c71dbf504058ced12d87d226b2b1b6
using:
$ gcc --version
gcc (GCC) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ld --version
GNU ld (GNU Binutils) 2.43
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
I got:
$ ../build2/x86/binutils/readelf -W -wo a.out
Contents of the .debug_loc section:
Offset Begin End Expression
00000000 0000000000001130 0000000000001138 (DW_OP_reg5 (rdi))
00000013 0000000000001138 0000000000001140 (DW_OP_GNU_entry_value:
(DW_OP_reg5 (rdi)); DW_OP_stack_value)
00000029 <End of list>
00000039 0000000000001131 0000000000001138 (DW_OP_reg5 (rdi))
0000004c 0000000000001138 0000000000001140 (DW_OP_consts: 123;
DW_OP_stack_value)
00000062 <End of list>
Table at Offset 0
Length: 0
DWARF version: 0
Address size: 0
Segment size: 0
Offset entries: 8
Offset Entries starting at 0xc:
[ 0] 0
[ 1] 0x8550001
[ 2] 0
[ 3] 0x10000000
[ 4] 0
[ 5] 0x4000000
[ 6] 0x5501f300
[ 7] 0x9f
Table at Offset 0x4
Length: 0
DWARF version: 8
Address size: 0
Segment size: 0
Offset entries: 0
Table at Offset 0x8
Length: 0x8
DWARF version: 0
Address size: 0
Segment size: 0
Offset entries: 139788289
Offset Entries starting at 0x14:
[ 0] 0
[ 1] 0x10000000
[ 2] 0
[ 3] 0x4000000
[ 4] 0x5501f300
and this last part keeps on going for quite a while until I finally hit ctrl+C
to stop. The same sort of output exists as near as I can tell as far back as
maybe binutils/2.43...
I also find that the header information here looks very suspicious when
compared to that provided by llvm-dwarfdump associated with the same clang
20.1.0 release:
$ llvm-dwarfdump --debug-loc --debug-loclists a.out
a.out: file format elf64-x86-64
.debug_loc contents:
0x00000000:
(0x0000000000000000, 0x0000000000000008): DW_OP_reg5 RDI
(0x0000000000000008, 0x0000000000000010):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
0x00000039:
(0x0000000000000001, 0x0000000000000008): DW_OP_reg5 RDI
(0x0000000000000008, 0x0000000000000010): DW_OP_consts +123,
DW_OP_stack_value
.debug_loclists contents:
locations list header: length = 0x0000001d, format = DWARF32, version = 0x0005,
addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000001
offsets: [
0x00000004
]
0x00000010:
DW_LLE_offset_pair (0x000000000000001b, 0x0000000000000025):
DW_OP_consts +123, DW_OP_stack_value
DW_LLE_offset_pair (0x0000000000000025, 0x0000000000000029):
DW_OP_consts +456, DW_OP_stack_value
Something seems more than a little off about that header information too.
--
You are receiving this mail because:
You are on the CC list for the bug.
