From: Michael Forney <mforney@mforney.org>
To: musl@lists.openwall.com
Subject: [musl] ld-musl-* and empty .eh_frame
Date: Thu, 04 Mar 2021 19:18:11 -0800 [thread overview]
Message-ID: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> (raw)
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.
GNU ld seems to always create a .eh_frame section in the final
executable (unless you pass --no-ld-generated-unwind-info), regardless
of whether any of the objects had one. Since none of the objects I
built have an .eh_frame and none of musl's crt*.o have one, it ends
up empty.
gcc does not have this problem because its crtend.o has a non-empty
.eh_frame (size is 4, so looks to be a CIE terminator according to LSB[0]).
Here's a short shell session demonstrating the problem:
$ cat t.s
.text
.globl main
main:
movl $123, %eax
ret
$ as -o t.o t.s
$ ld --dynamic-linker /lib/ld-musl-x86_64.so.1 -o t /lib/crt1.o /lib/crti.o t.o /lib/libc.so /lib/crtn.o
$ ./t ; echo $?
123
$ /lib/ld-musl-x86_64.so.1 ./t
/lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program
$ strace /lib/ld-musl-x86_64.so.1 ./t
execve("/lib/ld-musl-x86_64.so.1", ["/lib/ld-musl-x86_64.so.1", "./t"], 0x7ffd8c17e4e8 /* 34 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7f3691752aa8) = 0
set_tid_address(0x7f3691754fd8) = 31726
open("./t", O_RDONLY|O_LARGEFILE) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0 \20@\0\0\0\0\0"..., 960) = 960
mmap(0x400000, 16384, PROT_READ, MAP_PRIVATE, 3, 0) = 0x400000
mmap(0x401000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x401000
mmap(0x402000, 0, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = -1 EINVAL (Invalid argument)
munmap(0x400000, 16384) = 0
writev(2, ["/lib/ld-musl-x86_64.so.1: ./t: N"...59, NULL0], 2/lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program
) = 59
exit_group(1) = ?
+++ exited with 1 +++
$
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?
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.
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.
Or perhaps some combination of the four? Any insight is appreciated.
Thanks!
[0] https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html
next reply other threads:[~2021-03-05 3:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 3:18 Michael Forney [this message]
2021-03-05 15:07 ` Rich Felker
2021-03-05 16:12 ` Rich Felker
2021-03-05 22:53 ` Michael Forney
2021-03-06 1:14 ` Fangrui Song
2021-03-06 1:28 ` Rich Felker
2021-03-06 1:30 ` Michael Forney
2021-03-06 1:39 ` Fangrui Song
2021-03-06 2:04 ` Michael Forney
2021-03-06 2:09 ` Fangrui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org \
--to=mforney@mforney.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).