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

[Rich Felker <dalias@libc.org>]

On Fri, Mar 05, 2021 at 10:07:32AM -0500, Rich Felker wrote:
> 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.

In practice this probably does, but there's also something of a
question what to do if the zero-size segment is not page aligned. This
is not actually a mmap error since it will be automatically expanded
out to page boundaries in both directions, but if ld is capable of
emitting such segments they may be semantically wrong (mapping over
top of something else they're not intended to). Can you confirm that
ld isn't doing anything awful here?

Rich