Re: [musl] ld-musl-* and empty .eh_frame

[Rich Felker <dalias@libc.org>]

On Thu, Mar 04, 2021 at 07:18:11PM -0800, Michael Forney wrote:
> Hi,
> 
> Érico noticed that cproc (my C compiler) produced executables that
> musl's dynamic linker fails to load when passed as an argument:
> 
>   /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program
> 
> However, running ./t directly works fine. It turns out that this
> is because the executables have an empty .eh_frame section, which
> causes musl to attempt an mmap with length 0 which fails with EINVAL.

The section itself isn't the problem; rather the linker making a
dedicated PROT_READ segment with no non-zero-length sections in it is.
It really should have collapsed that out. (Also it would not happen
without the separate-text option, which mcm disables because it makes
lots of problems.)

With that said, there's no good reason we should error out on this;
it's syntactically and semantically valid just pointless for the
linker to emit. I think adding if (!n) return p; at the top of
mmap_fixed in dynlink.c fixes it.

> This leaves me with a few questions:
> 
> 1. Is it invalid for an ELF executable to have an empty .eh_frame
>    section? The only documentation I could find about it is [0],
>    which says that it must contain one or more CFI records, so 0
>    would be invalid.
> 2. Is it the compiler's responsibility to link with an object
>    containing a CIE terminator (like gcc's crtend.o) to prevent an
>    empty .eh_frame section?

Sections are irrelevant to an executable file so it doesn't matter
whatsoever. They're involved only in pre-link contracts and debugging.

> 3. Is it a bug that GNU ld creates an empty .eh_frame by default,
>    even when none of the objects it is linking have one? It looks
>    like lld does not create an .eh_frame in this case.

I don't think so. I think the bug is in the segment logic.

> 4. Should musl's ld.so be able to handle such executables? The
>    kernel does not seem to have a problem with it, as well glibc's
>    ld.so with an executable I crafted with a 0-length .eh_frame
>    section.

Yes.

Rich