[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210306020936.45kirg5cbj6d5aks@gmail.com>
Date: Fri, 5 Mar 2021 18:09:36 -0800
From: Fangrui Song <i@...kray.me>
To: musl@...ts.openwall.com
Subject: Re: ld-musl-* and empty .eh_frame
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.
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.
