[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAN30aBHEgB6SUaJ4G0tsKj20P_J0JnCwB7UQm+th=qDGavf+OA@mail.gmail.com>
Date: Sat, 21 Mar 2026 20:10:50 -0700
From: Fangrui Song <i@...kray.me>
To: Michael Forney <mforney@...rney.org>
Cc: musl@...ts.openwall.com
Subject: Re: ld-musl-* and empty .eh_frame
On Sun, Mar 15, 2026 at 2:35 AM Michael Forney <mforney@...rney.org> wrote:
>
> Fangrui Song <i@...kray.me> wrote:
> > On 2021-03-05, Michael Forney wrote:
> > >On 2021-03-05, Fangrui Song <i@...kray.me> wrote:
> > >> The empty .eh_frame is suspicious, though. There may be two problems:
> > >>
> > >> 1. Why do you have an empty .eh_frame in an object file
> > >
> > >There is no .eh_frame in any of the object files involved (neither t.o
> > >or crt*.o), just in the final executable. It seems that GNU ld creates
> > >a .eh_frame section unless you pass --no-ld-generated-unwind-info.
> > >
> > >> 2. Why does ld.bfd create empty .eh_frame in that case (I have tried
> > >> simple examples like `.section .eh_frame,"a"` and I cannot reproduce
> > >> the empty output .eh_frame)
> > >>
> > >> If you don't share the other files, it is difficult to locate the
> > >> problem.
> > >
> > >Which files are you interested in? The recipe I showed earlier should
> > >be sufficient to reproduce the issue. You can use the standard alpine
> > >linux toolchain (using /usr/lib instead of /lib for the paths to the
> > >crt*.o files). With a musl.cc toolchain, you'll need to pass -z
> > >separate-code to get the empty PT_LOAD segment, but the empty
> > >.eh_frame is there either way.
> >
> > You can build ld from the upstream binutils-gdb repo.
> > after configure, run `make -j30 all-ld` and use ld/ld-new.
> >
> > If you can reproduce, p_memsz==0 PT_LOAD in -z separate-code case deserves a bug.
>
> I had completely forgotten about this, but I randomly stumbled upon
> this thread again and thought I'd follow up.
>
> I checked and it's still an issue with latest binutils git (though
> somewhat hidden due to a recent change in .note.gnu.property
> handling).
>
> Here is how you can reproduce:
>
> $ cat >t.s <<'EOF'
> .text
> .globl _start
> _start:
> mov $60, %rax
> mov $123, %rdi
> syscall
> EOF
> $ as -o t.o t.s
> $ objcopy -R .note.gnu.property t.o t2.o
> $ ld -shared -o a.so /dev/null
> $ ld --no-dynamic-linker -o t t2.o a.so
> $ readelf -l t
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> <snip>
> LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000
> 0x0000000000000000 0x0000000000000000 R 0x1000
> <snip>
> $ readelf -S t
> Section Headers:
> [Nr] Name Type Address Offset
> Size EntSize Flags Link Info Align
> <snip>
> [ 7] .eh_frame PROGBITS 0000000000402000 00002000
> 0000000000000000 0000000000000000 A 0 0 8
> <snip>
> $
>
> Just wanted confirm with you that this is a bug before filing an
> issue on the binutils bug tracker.
(Thread: https://www.openwall.com/lists/musl/2021/03/06/4 Re:
ld-musl-* and empty .eh_frame)
Yes, please file a binutils bug. The p_memsz==0 PT_LOAD in the readelf
-Sl output is also invalid/suspicious.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x0001de 0x0001de R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x000010 0x000010 R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000
0x000000 0x000000 R 0x1000
LOAD 0x002f20 0x0000000000402f20 0x0000000000402f20
0x0000e0 0x0000e0 RW 0x1000
DYNAMIC 0x002f20 0x0000000000402f20 0x0000000000402f20
0x0000e0 0x0000e0 RW 0x8
GNU_RELRO 0x002f20 0x0000000000402f20 0x0000000000402f20
0x0000e0 0x0000e0 R 0x1
Section to Segment mapping:
Segment Sections...
00 .hash .gnu.hash .dynsym .dynstr
01 .text
02 .eh_frame
03 .dynamic
04 .dynamic
05 .dynamic
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
