* open64 and similar @ 2019-07-10 22:03 Andrew Bell 2019-07-10 22:43 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Andrew Bell @ 2019-07-10 22:03 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 396 bytes --] musl does the following: #define open64 open This can cause an infinite loop for the following code: class Foo { public: int open64() { open(); } }; Perhaps it would be better to supply open64 and have it call open, rather than #define it? There are several other xxx64 functions also defined that could cause problems with unfortunate code. -- Andrew Bell andrew.bell.ia@gmail.com [-- Attachment #2: Type: text/html, Size: 743 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open64 and similar 2019-07-10 22:03 open64 and similar Andrew Bell @ 2019-07-10 22:43 ` Rich Felker 2019-07-11 1:58 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Rich Felker @ 2019-07-10 22:43 UTC (permalink / raw) To: musl On Wed, Jul 10, 2019 at 06:03:51PM -0400, Andrew Bell wrote: > musl does the following: > > #define open64 open > > This can cause an infinite loop for the following code: > > class Foo > { > public: > int open64() > { open(); } > }; > > Perhaps it would be better to supply open64 and have it call open, rather > than #define it? There are several other xxx64 functions also defined that > could cause problems with unfortunate code. The intent is that we're trying to prevent actual references to the legacy open64, etc. symbols while supporting code that's wrongly attempting to use them. At the time this was added, that was still a problem in lots of software; I don't know if it's since been fixed. Originally, the intent was that the symbols exist *only* as ABI, for ABI-compat loading of glibc-linked libs, and not as API that programs compiled against musl could use. However broken configure scripts checked for the symbol definition by linking a test program using a *fake* declaration of the symbol, without including the header, then wrongly picked up that it was available, and compiled wrong code later at compiel time due to implicit-function-declaration. So the macro redirections were added. I'd like it if we could remove this stuff entirely, except for the ABI-compat. Maybe it could be done by getting rid of the actual symbols and just putting magic in the dynamic linker to resolve them to the non-64 ones. Anyway, this is not the first time someone's hit a problem from it with C++, which is caused by GCC's unconditional (and wrong) definition of _GNU_SOURCE in C++ mode. So we really should try to find a reasonable fix... Rich ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open64 and similar 2019-07-10 22:43 ` Rich Felker @ 2019-07-11 1:58 ` Rich Felker 0 siblings, 0 replies; 3+ messages in thread From: Rich Felker @ 2019-07-11 1:58 UTC (permalink / raw) To: musl On Wed, Jul 10, 2019 at 06:43:01PM -0400, Rich Felker wrote: > I'd like it if we could remove this stuff entirely, except for the > ABI-compat. Maybe it could be done by getting rid of the actual > symbols and just putting magic in the dynamic linker to resolve them > to the non-64 ones. Since I'd like to actually go forward with this in the next release cycle, an outline for how it would work: Removal is simple: just ripping out all the _LARGEFILE64_SOURCE stuff from the headers and all instances of weak_alias(x,x64) (and the few exceptions to this pattern) from the source files. Restoration/preservation of glibc-ABI-compat (and ABI-compat with any musl binaries that might have somehow found a way to produce a reference to one of the *64 symbols) is harder. There are two possible approaches. One is to add to dynlink.c a special case for symbol lookup failure in libc.so, whereby, for a list of symbol names, the lookup is retried with the 64 removed (or with other transformations as needed). A second, possibly more graceful, way to do it is to generate as static data an ELF symbol table for all the symbols that we want to offer as ABI-compat only, and add a dummy DSO to the DSO list at dynamic linker startup, just after libc.so, to hook up the symbol table for the existing normal code paths to use. A third, awful possibility would be using symbol versioning to set them up as non-default (invisible to ld) versioned symbols aliased to the real functions. There are lots of good reasons not to want to do this (and not to want any symver table in libc, even if we do actually want to resolve symbol versions for other libs later). My leaning is towards the second option since it's rather elegant, non-invasive to the hot code paths, and easy to extend to other "junk" symbols we might want to offer for ABI-compat only. But I'm also open to simpler ideas. For example if there's a way to "poison" the symbols to ld so that it refuses to link to them (generating errors when configure scripts try), that should suffice without removing the symbols, and would be easier (and avoid the need for any special dynamic linker work). Note that if we do this, we might also want to offer a static liblfs64.a that just redirects all the LFS64 symbols to the standard ones (this is mildly annoying to do for open64, since it's variadic...). This is to allow ABI-compat linking of static (possibly closed-source) libs that were made for use with glibc, to the extent possible, and is not something you'd want to do by default since it would expose the symbols to configure scripts again. Rich ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-11 1:58 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-10 22:03 open64 and similar Andrew Bell 2019-07-10 22:43 ` Rich Felker 2019-07-11 1:58 ` Rich Felker
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).