cmd/link: DWARF5 output causes ~60,000 readelf warnings - incorrect DW_FORM_addrx offset calculation

[kajaaz]

Go version

go version go1.25.6 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/xxx/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/xxx/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3231229538=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/xxx/Documents/optrollups/go-ethereum/go.mod'
GOMODCACHE='/home/xxx/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/xxx/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/xxx/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.25.6'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Built a large Go project (go-ethereum) with Go 1.25.6 and analyzed the DWARF debug information with GNU readelf:

git clone https://github.com/ethereum/go-ethereum
cd go-ethereum
# remove the flags '--strip-all' and '-trimpath' from the /build/ci.go file, add the flag '-gcflags all=-N -l'
make geth
readelf --debug-dump=info ./build/bin/geth 2>&1 | grep -c "readelf: Warning"
# Output: 60877

What did you see happen?

Building with Go 1.25.6 (DWARF5 enabled by default) produces 60,877 readelf warnings:

readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
readelf: Warning: Offset into section .debug_addr too big: 0x47002e08
readelf: Warning: Offset into section .debug_addr too big: 0x47002e10
...

Example of failing function DIE:

<57>   DW_AT_addr_base   : 0x8
 <1><5b>: Abbrev Number: 3 (DW_TAG_subprogram)
    <5c>   DW_AT_name        : crypto/internal/fips140/ecdh.ecdh[go.shape.*crypto/internal/fips140/nistec.P256Point]
    <b2>   DW_AT_low_pc      :readelf: Warning: Offset into section .debug_addr too big: 0x47002e00

The compilation unit has DW_AT_addr_base: 0x8, which is correct. However, readelf computes offset 0x47002e00 instead of the expected small offset.
If we reverse the calculation:

• readelf uses: offset = addr_base + (index × 8)
• 0x47002e00 = addr_base + (index × 8)
• This implies readelf is using addr_base ≈ 0x47002e00 instead of 0x8

The value 0x47 is ASCII 'G', suggesting readelf may be misreading unrelated data (possibly from strings like "github.com/...") as the addr_base.

Tools versions:

$ readelf --version
GNU readelf (GNU Binutils for Ubuntu) 2.42
$ readelf --debug-dump=info ./build/bin/geth 2>/dev/null | grep "Version:" | head -3
   Version:       5
   Version:       5
   Version:       5

What did you expect to see?

I expected readelf to parse the DWARF5 debug information without warnings and resolve function addresses correctly using the DW_AT_addr_base attribute.
Expected:

• DW_AT_low_pc should resolve to actual function addresses
• No "Offset into section .debug_addr too big" warnings
• DWARF consumers (debuggers, binary analysis tools) should work correctly

This breaks DWARF-based debugging and analysis tools including:

• GDB debugger
• Binary analysis frameworks (angr, Ghidra DWARF import)
• Security research tools for vulnerability analysis
• Any tool using libdwarf/libdw to parse Go binaries

Possible causes:

• The DWARF5 .debug_addr section format may not match what binutils expects
• The relationship between compilation unit boundaries and DW_AT_addr_base scope may be malformed
• There may be an issue with how DW_FORM_addrx indices are encoded or how they relate to the addr_base

Investigation notes:

• The .debug_addr section exists and has a valid DWARF5 header
• DW_AT_addr_base values are present in compilation units and appear reasonable (0x8, 0x130, etc.)
• The indices stored in DW_FORM_addrx attributes are small valid numbers
• But readelf computes wildly incorrect offsets (0x47002e00, 0x47002e08, etc.)
• This was tested with binutils 2.42 (Ubuntu current) - latest available is 2.45

[gabyhelp]

Related Issues

• Disable DWARF 5 in Go 1.25 #75079 (closed)
• cmd/compile: generated DWARF triggers objdump warning for large uint64 const #39048
• cmd/link: DWARF5 implementation breaks debugedit #76630
• cmd/compile: bad inlining informations in debug_info with DWARFv5 on tip #72821 (closed)
• cmd/link: slow link times with large amounts of DWARF data #75508
• cmd/compile: consider using DWARF 5 #26379 (closed)
• gccgo: objdump -DlS on gccgo-built program fails with: Dwarf Error: found dwarf version '25106', this reader only handles version 2, 3, 4 and 5 information. #44091 (closed)
• debug/elf: does not properly apply DWARF RELA relocations #40879 (closed)

Related Code Changes

• cmd/link: use .debug_line_str for DWARF 5

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @thanm @golang/compiler

[Oguidan]

CC @thanm @golang/compiler

Hi, please can you explain to me why is the compiler the issue. I will like to know

[ianlancetaylor]

I don't know for sure that the compiler is the issue. Both the compiler and the linker generate DWARF information. This bug appears to be saying that DWARF contains incorrect DW_FORM_addrx values, values that are an absolute address rather than an offset into the .debug_addr section. Or it could be something else entirely, I'm not sure. But the compiler seems like the place to start.

[Oguidan]

I don't know for sure that the compiler is the issue. Both the compiler and the linker generate DWARF information. This bug appears to be saying that DWARF contains incorrect DW_FORM_addrx values, values that are an absolute address rather than an offset into the .debug_addr section. Or it could be something else entirely, I'm not sure. But the compiler seems like the place to start.

I see, thanks 😊. Good way of diagnostic

[thanm]

Thanks for the report. I will take a look later this week.

I note that this seems to happen only with external linking, I get no warnings when building Go programs with just the Go toolchain (internal linking). With this in mind, if you could please post some info on which C compiler and C linker you are using, that would be great. Example:

% which cc
/usr/bin/cc
% cc --versio
cc (Debian 14.2.0-19) 14.2.0
...
% cc -Wl,-v himom.c 
collect2 version 14.2.0
...
GNU ld (GNU Binutils for Debian) 2.44
% 

Thanks.

[Oguidan]

Thanks for the report. I will take a look later this week.

I note that this seems to happen only with external linking, I get no warnings when building Go programs with just the Go toolchain (internal linking). With this in mind, if you could please post some info on which C compiler and C linker you are using, that would be great. Example:

% which cc
/usr/bin/cc
% cc --versio
cc (Debian 14.2.0-19) 14.2.0
...
% cc -Wl,-v himom.c 
collect2 version 14.2.0
...
GNU ld (GNU Binutils for Debian) 2.44
% 

Thanks.

Hi @thanm , please I will like to fix it with you so I could learn

[thanm]

Hi @thanm , please I will like to fix it with you so I could learn

OK @Oguidan I will try to post additional details of what I'm trying as I work on this.

FWIW it's not completely clear that the problem is with Go as opposed to the C linker (given that the bad scenario only seems to crop up with external linking). My first steps will be to try to learn more about that.

It's also not out of the realm of possibility that there is some issue with how "readelf" is digesting the DWARF info produced by Go.

@kajaaz please don't forget to post the C compiler and linker version info as requested.

FWIW I can reproduce this problem (or something similar) by forcing external linking using a toy Go program:

$ rm -f himom.exe ; CC=gcc go build -trimpath -ldflags=-linkmode=external -o himom.exe himom.go
$ readelf --debug-dump=info himom.exe 1> /dev/null 2> /tmp/err.txt
$ head -2 /tmp/err.txt
readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
readelf: Warning: Offset into section .debug_addr too big: 0x47002e08
$

Here the external linker is gcc with the BFD linker.

[Oguidan]

Hi @thanm , please I will like to fix it with you so I could learn

OK @Oguidan I will try to post additional details of what I'm trying as I work on this.

FWIW it's not completely clear that the problem is with Go as opposed to the C linker (given that the bad scenario only seems to crop up with external linking). My first steps will be to try to learn more about that.

It's also not out of the realm of possibility that there is some issue with how "readelf" is digesting the DWARF info produced by Go.

@kajaaz please don't forget to post the C compiler and linker version info as requested.

FWIW I can reproduce this problem (or something similar) by forcing external linking using a toy Go program:

$ rm -f himom.exe ; CC=gcc go build -trimpath -ldflags=-linkmode=external -o himom.exe himom.go
$ readelf --debug-dump=info himom.exe 1> /dev/null 2> /tmp/err.txt
$ head -2 /tmp/err.txt
readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
readelf: Warning: Offset into section .debug_addr too big: 0x47002e08
$

Here the external linker is gcc with the BFD linker.

Thank you very much,

But is the error present with different C linker

[thanm]

First experiment: try building with a different C compiler and linker. Here is a build using clang as compiler driver and LLD as linker:

$ rm -f himom.exe ; CC=clang-16 go build -trimpath -ldflags="-linkmode=external -extldflags=-fuse-ld=lld" -o himom.exe himom.go
$ readelf --debug-dump=info himom.exe 1> /dev/null 2> /tmp/err.txt
$ head -2 /tmp/err.txt
readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
readelf: Warning: Offset into section .debug_addr too big: 0x47002e08
$

This shows that the problem is (ostensibly) still there even with different C linker.

On the other hand, running the LLVM dwarf dump tool on the resulting binary produces output without any errors:

$ llvm-dwarfdump-16 --all himom.exe > /dev/null
$

Also when I look at the spot in the LLVM dwarfdump output where "readelf" is falling down, it looks fine. Here is readelf (note the error at offset 0x9b):

 <1><82>: Abbrev Number: 3 (DW_TAG_subprogram)
    <83>   DW_AT_name        : syscall.rawVforkSyscall
    <9b>   DW_AT_low_pc      :readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
 (index: 0): 0
    <9f>   DW_AT_high_pc     : 88
    <a0>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <a2>   DW_AT_decl_file   : 0x1
    <a6>   DW_AT_decl_line   : 15
    <a7>   DW_AT_external    : 1

and here's the equivalent section from llvm-dwarfdump:

0x00000082:   DW_TAG_subprogram
                DW_AT_name	("syscall.rawVforkSyscall")
                DW_AT_low_pc	(0x0000000000386440)
                DW_AT_high_pc	(0x0000000000386498)
                DW_AT_frame_base	(DW_OP_call_frame_cfa)
                DW_AT_decl_file	("./syscall/asm_linux_amd64.s")
                DW_AT_decl_line	(15)
                DW_AT_external	(0x01)

If llvm-dwarfdump is producing results without any errors, IMHO this points the finger at readelf.

I built a debuggable copy of readelf as follows:

$ mkdir cd /tmp/w
$ cd /tmp/w
$ git clone https://gnu.googlesource.com/binutils-gdb
...
$ mkdir build
$ cd build
$ ../binutils-gdb/configure  --prefix=/tmp/w/binutils/install \
    CFLAGS="-O0 -g" CXXFLAGS="-O0 -g" CPPFLAGS="-O0 -g" \
    CFLAGS_FOR_BUILD="-O0 -g" CXXFLAGS_FOR_BUILD="-O0 -g" CPPFLAGS_FOR_BUILD="-O0 -g"
...
$ make -j20 all
...
$ make install
...
$ cd ../install
$ ls bin/readelf
bin/readelf
$

At this point I fired up a copy of GDB on the newly built readelf and ran it on my himom.exe file.

$ gdb readelf
Current directory is /tmp
GNU gdb (Debian 16.3-1) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
...
Reading symbols from readelf...
(gdb) b main 
Breakpoint 1 at 0x55840: file ../../binutils-gdb/binutils/readelf.c, line 25428.
(gdb) b warn
Breakpoint 3 at 0x8aff1: file ../../binutils-gdb/binutils/elfcomm.c, line 58.
(gdb) run --debug-dump himom.extlink.exe
...
Breakpoint 3.1, warn (
    message=0x555555666848 "Offset into section %s too big: %#lx\n")
    at ../../binutils-gdb/binutils/elfcomm.c:58
(gdb) up
#1  0x00005555555ad41e in fetch_indexed_addr (offset=1191194112, num_bytes=8)
    at ../../binutils-gdb/binutils/dwarf.c:714
(gdb) p offset
$1 = 1191194112
(gdb) p /x offset
$2 = 0x47002e00
(gdb) up
#2  0x00005555555b62e9 in read_and_display_attr_value (attribute=17, form=27, 
    implicit_const=-1, start=0x7ffff7bc4010 <incomplete sequence \317>, 
    data=0x7ffff7bc40af "X\001\234\001", end=0x7ffff7bc40e3 "\370\n", 
    cu_offset=0, pointer_size=8, offset_size=4, dwarf_version=5, 
    debug_info_p=0x5555556cff80, do_loc=0, 
    section=0x55555569e530 <debug_displays+336>, this_set=0x0, 
    delimiter=32 ' ', level=1) at ../../binutils-gdb/binutils/dwarf.c:2919
(gdb) p debug_info_p->addr_base
$3 = 1191194112
(gdb) p /x debug_info_p->addr_base
$4 = 0x47002e00

Note the bad value for addr_base -- the Go toolchain emits these values, and we would not get any number this large for a small program (addr_base is a section offset). This suggests that by the time we hit this warning the value has been incorrectly read or corrupted somehow.

This section of code that triggers the warning (dwarf.c line 2919) is trying to dump out a value of form DW_FORM_addrx, the pertinent code is

	      if (debug_info_p == NULL)
		base = 0;
	      else if (debug_info_p->addr_base == DEBUG_INFO_UNAVAILABLE)
		base = 0;
	      else
		base = debug_info_p->addr_base;

	      base += uvalue * pointer_size;
	      idx = fetch_indexed_addr (base, pointer_size);

Here 'debug_info_p' is a struct of type debug_info defined in dwarf.h -- the comments are not great but it looks like something that is filled in to hold information about a compilation unit in the DWARF .debug_info section.

So how did this bad value come about? Let's set a watchpoint on it and see where it is changing.

(gdb) watch -location debug_info_p->addr_base
Hardware watchpoint 5: -location debug_info_p->addr_base
(gdb) run
...
Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = <unreadable>
New value = 0
__memset_avx512_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:237
warning: 237	../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory
(gdb)

This first change to the value is in initialization -- we can ignore this. Continuing:

(gdb) c
Continuing.

Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = 0
New value = 4294967295
process_debug_info (section=0x55555569e530 <debug_displays+336>, 
    file=0x5555556a6310, abbrev_sec=abbrev, do_flags=1)
    at ../../binutils-gdb/binutils/dwarf.c:4120
(gdb) p /x debug_information[unit].addr_base
$20 = 0xffffffff
(gdb) c
Continuing.

This second modification above corresponds to this line at 4120:

	  debug_information[unit].ranges_base = DEBUG_INFO_UNAVAILABLE;

in other words, more initialization. Continuing on:

(gdb) c
Continuing.

Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = 4294967295
New value = 1191194112
read_bases (entry=0x5555556f05b0, 
    data=0x7ffff7bc4039 "o cmd/compile go1.27-devel_455282911a Wed Jan 21 12:27:12 2026 -0800; regabi", end=0x7ffff7bc40e3 "\370\n", pointer_size=8, 
    offset_size=4, dwarf_version=5, debug_info_p=0x5555556cff80)
    at ../../binutils-gdb/binutils/dwarf.c:3811
(gdb) up
#1  0x00005555555bb4da in process_debug_info (
    section=0x55555569e530 <debug_displays+336>, file=0x5555556a6310, 
    abbrev_sec=abbrev, do_flags=1) at ../../binutils-gdb/binutils/dwarf.c:4340
(gdb) down
#0  read_bases (entry=0x5555556f05b0, 
    data=0x7ffff7bc4039 "o cmd/compile go1.27-devel_455282911a Wed Jan 21 12:27:12 2026 -0800; regabi", end=0x7ffff7bc40e3 "\370\n", pointer_size=8, 
    offset_size=4, dwarf_version=5, debug_info_p=0x5555556cff80)
    at ../../binutils-gdb/binutils/dwarf.c:3811
(gdb) 
Bottom (innermost) frame selected; you cannot go down.
(gdb) p /x 1191194112
$21 = 0x47002e00
(gdb) p /x uvalue
$22 = 0x47002e00

Ok, we've found our bad value. For some reason read_bases is filling it in with junk.

To make a long story short, it looks as though readelf has two paths for filling in the addr_base value: one in read_and_display_attr_value (which seems to get the correct value of 8) and one in read_bases, which fills in the junk value.

I took a closer look at read_bases. This routine was added in binutils commit 84102ebc29a1ea531e7fe78bd841bfb2fe501dc2 ; its sole job is to filter through CU DIE attributes and pick out specific ones (including addr_base) ahead of time. The filtering uses a helper routine skip_attribute (called only from read_bases) that given an attribute skips past the data payload for the attribute.

I spent a half hour debugging read_bases and skip_attribute. As read_bases is cycling through the compilation unit DIE looking for attributes of interest, I found that the data point it is maintaining becomes corrupted -- pointing earlier in the data section than it should.

Finally I narrowed it down to this piece of code near 3747 in skip_attribute:

    case DW_FORM_string:
      inc = strnlen ((char *) data, end - data);
      break;

There is an off-by-one error here, it should be adding in 1 so as to skip past the terminating nul byte. When I make this change to the readelf source (e.g. inc = strnlen ((char *) data, end - data) + 1; and rebuild, the DWARF dump works fine.

Probably best to file a binutils bug at this point.

---

First experiment: try building with a different C compiler and linker. Here is a build using clang as compiler driver and LLD as linker:

$ rm -f himom.exe ; CC=clang-16 go build -trimpath -ldflags="-linkmode=external -extldflags=-fuse-ld=lld" -o himom.exe himom.go
$ readelf --debug-dump=info himom.exe 1> /dev/null 2> /tmp/err.txt
$ head -2 /tmp/err.txt
readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
readelf: Warning: Offset into section .debug_addr too big: 0x47002e08
$

This shows that the problem is (ostensibly) still there even with different C linker.

On the other hand, running the LLVM dwarf dump tool on the resulting binary produces output without any errors:

$ llvm-dwarfdump-16 --all himom.exe > /dev/null
$

Also when I look at the spot in the LLVM dwarfdump output where "readelf" is falling down, it looks fine. Here is readelf (note the error at offset 0x9b):

 <1><82>: Abbrev Number: 3 (DW_TAG_subprogram)
    <83>   DW_AT_name        : syscall.rawVforkSyscall
    <9b>   DW_AT_low_pc      :readelf: Warning: Offset into section .debug_addr too big: 0x47002e00
 (index: 0): 0
    <9f>   DW_AT_high_pc     : 88
    <a0>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <a2>   DW_AT_decl_file   : 0x1
    <a6>   DW_AT_decl_line   : 15
    <a7>   DW_AT_external    : 1

and here's the equivalent section from llvm-dwarfdump:

0x00000082:   DW_TAG_subprogram
                DW_AT_name	("syscall.rawVforkSyscall")
                DW_AT_low_pc	(0x0000000000386440)
                DW_AT_high_pc	(0x0000000000386498)
                DW_AT_frame_base	(DW_OP_call_frame_cfa)
                DW_AT_decl_file	("./syscall/asm_linux_amd64.s")
                DW_AT_decl_line	(15)
                DW_AT_external	(0x01)

If llvm-dwarfdump is producing results without any errors, IMHO this points the finger at readelf.

I built a debuggable copy of readelf as follows:

$ mkdir cd /tmp/w
$ cd /tmp/w
$ git clone https://gnu.googlesource.com/binutils-gdb
...
$ mkdir build
$ cd build
$ ../binutils-gdb/configure  --prefix=/tmp/w/binutils/install \
    CFLAGS="-O0 -g" CXXFLAGS="-O0 -g" CPPFLAGS="-O0 -g" \
    CFLAGS_FOR_BUILD="-O0 -g" CXXFLAGS_FOR_BUILD="-O0 -g" CPPFLAGS_FOR_BUILD="-O0 -g"
...
$ make -j20 all
...
$ make install
...
$ cd ../install
$ ls bin/readelf
bin/readelf
$

At this point I fired up a copy of GDB on the newly built readelf and ran it on my himom.exe file.

$ gdb readelf
Current directory is /tmp
GNU gdb (Debian 16.3-1) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
...
Reading symbols from readelf...
(gdb) b main 
Breakpoint 1 at 0x55840: file ../../binutils-gdb/binutils/readelf.c, line 25428.
(gdb) b warn
Breakpoint 3 at 0x8aff1: file ../../binutils-gdb/binutils/elfcomm.c, line 58.
(gdb) run --debug-dump himom.extlink.exe
...
Breakpoint 3.1, warn (
    message=0x555555666848 "Offset into section %s too big: %#lx\n")
    at ../../binutils-gdb/binutils/elfcomm.c:58
(gdb) up
#1  0x00005555555ad41e in fetch_indexed_addr (offset=1191194112, num_bytes=8)
    at ../../binutils-gdb/binutils/dwarf.c:714
(gdb) p offset
$1 = 1191194112
(gdb) p /x offset
$2 = 0x47002e00
(gdb) up
#2  0x00005555555b62e9 in read_and_display_attr_value (attribute=17, form=27, 
    implicit_const=-1, start=0x7ffff7bc4010 <incomplete sequence \317>, 
    data=0x7ffff7bc40af "X\001\234\001", end=0x7ffff7bc40e3 "\370\n", 
    cu_offset=0, pointer_size=8, offset_size=4, dwarf_version=5, 
    debug_info_p=0x5555556cff80, do_loc=0, 
    section=0x55555569e530 <debug_displays+336>, this_set=0x0, 
    delimiter=32 ' ', level=1) at ../../binutils-gdb/binutils/dwarf.c:2919
(gdb) p debug_info_p->addr_base
$3 = 1191194112
(gdb) p /x debug_info_p->addr_base
$4 = 0x47002e00

Note the bad value for addr_base -- the Go toolchain emits these values, and we would not get any number this large for a small program (addr_base is a section offset). This suggests that by the time we hit this warning the value has been incorrectly read or corrupted somehow.

This section of code that triggers the warning (dwarf.c line 2919) is trying to dump out a value of form DW_FORM_addrx, the pertinent code is

	      if (debug_info_p == NULL)
		base = 0;
	      else if (debug_info_p->addr_base == DEBUG_INFO_UNAVAILABLE)
		base = 0;
	      else
		base = debug_info_p->addr_base;

	      base += uvalue * pointer_size;
	      idx = fetch_indexed_addr (base, pointer_size);

Here 'debug_info_p' is a struct of type debug_info defined in dwarf.h -- the comments are not great but it looks like something that is filled in to hold information about a compilation unit in the DWARF .debug_info section.

So how did this bad value come about? Let's set a watchpoint on it and see where it is changing.

(gdb) watch -location debug_info_p->addr_base
Hardware watchpoint 5: -location debug_info_p->addr_base
(gdb) run
...
Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = <unreadable>
New value = 0
__memset_avx512_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:237
warning: 237	../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory
(gdb)

This first change to the value is in initialization -- we can ignore this. Continuing:

(gdb) c
Continuing.

Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = 0
New value = 4294967295
process_debug_info (section=0x55555569e530 <debug_displays+336>, 
    file=0x5555556a6310, abbrev_sec=abbrev, do_flags=1)
    at ../../binutils-gdb/binutils/dwarf.c:4120
(gdb) p /x debug_information[unit].addr_base
$20 = 0xffffffff
(gdb) c
Continuing.

This second modification above corresponds to this line at 4120:

	  debug_information[unit].ranges_base = DEBUG_INFO_UNAVAILABLE;

in other words, more initialization. Continuing on:

(gdb) c
Continuing.

Hardware watchpoint 5: -location debug_info_p->addr_base

Old value = 4294967295
New value = 1191194112
read_bases (entry=0x5555556f05b0, 
    data=0x7ffff7bc4039 "o cmd/compile go1.27-devel_455282911a Wed Jan 21 12:27:12 2026 -0800; regabi", end=0x7ffff7bc40e3 "\370\n", pointer_size=8, 
    offset_size=4, dwarf_version=5, debug_info_p=0x5555556cff80)
    at ../../binutils-gdb/binutils/dwarf.c:3811
(gdb) up
#1  0x00005555555bb4da in process_debug_info (
    section=0x55555569e530 <debug_displays+336>, file=0x5555556a6310, 
    abbrev_sec=abbrev, do_flags=1) at ../../binutils-gdb/binutils/dwarf.c:4340
(gdb) down
#0  read_bases (entry=0x5555556f05b0, 
    data=0x7ffff7bc4039 "o cmd/compile go1.27-devel_455282911a Wed Jan 21 12:27:12 2026 -0800; regabi", end=0x7ffff7bc40e3 "\370\n", pointer_size=8, 
    offset_size=4, dwarf_version=5, debug_info_p=0x5555556cff80)
    at ../../binutils-gdb/binutils/dwarf.c:3811
(gdb) 
Bottom (innermost) frame selected; you cannot go down.
(gdb) p /x 1191194112
$21 = 0x47002e00
(gdb) p /x uvalue
$22 = 0x47002e00

Ok, we've found our bad value. For some reason read_bases is filling it in with junk.

To make a long story short, it looks as though readelf has two paths for filling in the addr_base value: one in read_and_display_attr_value (which seems to get the correct value of 8) and one in read_bases, which fills in the junk value.

I took a closer look at read_bases. This routine was added in binutils commit 84102ebc29a1ea531e7fe78bd841bfb2fe501dc2 ; its sole job is to filter through CU DIE attributes and pick out specific ones (including addr_base) ahead of time. The filtering uses a helper routine skip_attribute (called only from read_bases) that given an attribute skips past the data payload for the attribute.

I spent a half hour debugging read_bases and skip_attribute. As read_bases is cycling through the compilation unit DIE looking for attributes of interest, I found that the data point it is maintaining becomes corrupted -- pointing earlier in the data section than it should.

Finally I narrowed it down to this piece of code near 3747 in skip_attribute:

    case DW_FORM_string:
      inc = strnlen ((char *) data, end - data);
      break;

There is an off-by-one error here, it should be adding in 1 so as to skip past the terminating nul byte. When I make this change to the readelf source (e.g. inc = strnlen ((char *) data, end - data) + 1; and rebuild, the DWARF dump works fine.

Ordinarily this would be big show-stopper type bug, but as things would have it most C compilers use different formats for strings (e.g. DW_form_strp) so that might explain why it hasn't been run into earlier.

Probably best for us to file a binutils bug at this point.

I will also start thinking about whether we could come up with some sort of workaround for this problem in the Go toolchain -- one weird possibility would be to reorder CU DIE attributes to place the addr_base attribute first -- it would look strange but I think it might avoid the binutils bug.