[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGw6cBviZQE_+72=PQetqs8OuGvmfBNo8q=1qE-y5X8kg2dKJg@mail.gmail.com>
Date: Fri, 5 Mar 2021 18:04:56 -0800
From: Michael Forney <mforney@...rney.org>
To: musl@...ts.openwall.com
Subject: Re: ld-musl-* and empty .eh_frame
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.
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.
