[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220926010339.GA9709@brightrain.aerifal.cx>
Date: Sun, 25 Sep 2022 21:03:40 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Revisiting LFS64 removal
Seeing a recent wrong-fix commit in binutils
(https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=fe39ffdc202f04397f31557f17170b40bc42b77a)
reminded me of the longstanding "we need to remove LFS64" issue.
To recap the story here, musl originally include the LFS64 (open64,
lseek64, etc.) interfaces as a glibc-ABI-compat measure. I can't find
the exact location where it's discussed in the project history, but my
recollection of what happened was that this caused configure scripts
doing link-only testing to determine that these functions exist then
try to use them (without declarations, leading to catastrophic
breakage like truncation of pointers in return values.
Then commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c came along and
exposed these as public interfaces, but only as macros, to avoid
further linking to the unwanted symbols. (I'll note that the commit
message seems wrong, as it talks about possibly eventually adding weak
alias symbols, but those already existed since the start.)
It turns out that adding the macros was a really bad idea. While
they're only exposed with _GNU_SOURCE, g++ always defines _GNU_SOURCE,
and various things have broken in the same mode as the above binutils
commit was trying to fix.
Of course these interfaces should not be used, and we never intended
for them to be used just there for linking-compat. So, I've wanted to
get rid of them for a long time now.
I believe the simplest short-term way is probably going to be just
having the dynamic linker symbol lookup error path make one final
check before bailing out with an error:
- If the symbol to lookup ends in "64"..
- ..and it's in a hard-coded list of LFS64-compat symbols..
- ..and looking up the name with the "64" removed in libc succeeds..
Then use the version without the "64" suffix and go on with relocation
processing.
Hopefully this will not affect performance in non-error code paths
whatsoever.
In the long term, I still want to aim to move *all* the
glibc-ABI-compat symbols out of musl and into the gcompat project's
jurisdiction, and work on mechanisms for ldso to automatically load
gcompat where "libc.so.6" is referenced.
Does the above plan present any non-obvious problems? The only
limitation I'm aware of is that it only works for dynamic linking not
static. I don't really see this as a problem, as if you're static
linking .a's/.o's made for glibc, you can use tooling to patch them up
first.
Rich
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.
