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.