lto linking, missing symbols #24
Comments
|
Long term known problem with LTO and LD versioning scripts and GCC [1]. Has been brought up with FUSE [2] last year, too. Clang has some issues with LTO too, but that's a different story. Maybe this will work with GCC 9… [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 |
|
Thanks for the explanation, feel free to close, |
|
Given that -flto can probably be used along with some other options that mitigate this problem, |
|
I looked briefly at what it would take to detect problematic CC/CFLAGS settings within configure, and it doesn't look easy. It is finicky to write autoconf tests involving multiple object files, but I've done that before. The main problem is, for an accurate check we would need to run libtool, but libtool doesn't even exist until config.status runs. If someone could clue me in how to run ltmain.sh from within configure and have it behave as if it were the generated libtool, I could take it the rest of the way, but I don't have time to figure out that part myself. "make check" does detect the problem, at least. For now I think we should leave this bug open and mention it in the README. |
* README.md: mention yescrypt * README.md: document required tools for building from a Git checkout (issue #23) * README.md: document that -flto cannot be used due to incompatibility with symbol versioning (issue #24) * README.md: use curly quotes and apostrophes; use out-of-line hyperlinks for better readability as plain text * AUTHORS: say that the sunmd5 hash module is a clean-room reimplementation to avoid the CDDL * THANKS: move prior contributor credits here from README; alphabetize; mention Dmitry Levin, Alec Muffett, and Colin Percival * crypt_gensalt.3: document errno codes that can occur when obtaining random bytes from the operating system fails
|
Documented the limitation in 6b06074. I'm still happy to write a configure check if someone tells me how to run libtool from inside configure. |
|
@besser82 Neat. I wonder what they did to make it work. I'll maybe see if I can fix the tests. |
|
Re-opening as GCC 10.2 supports the needed initial bits now. |
GCC 10.2 and LLVM/Clang offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their visibility attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this, the exported versioned symbols need their attributes declared explicitly. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
|
Here's a different perspective, which might or might not be helpful: LTO feels primarily like an unjustified risk to me: exposing potential cross-translation-unit instances of undefined behavior, making them actually manifest themselves, sometimes as security vulnerabilities. Do we really want that? What for? Instead of supporting LTO, how about explicitly not supporting it - making attempted builds with LTO fail and not produce output files? Document that libxcrypt must not be built with LTO. Maybe add a flag to "support" and enable build with LTO for stress-testing only (not production), so that we get a chance to detect and fix some of those instances of UB ourselves before someone possibly reuses the code somewhere with LTO or merges source files. Somehow ensure that build wouldn't be inadvertently usable in production. BTW, I recall @besser82 also wanted to support build with auto-merging of source files, which would have similar bug-exposing and security implications, and I similarly advised against that except maybe as a stress-test. I'm no LTO expert, and am not up to date on whether it's somehow possibly required somewhere in the ecosystem now. Please correct me if so. |
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10.2 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10.2, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
GCC 10 and LLVM/Clang 10 offer initial support for building libraries, that are using symbol versioning features, with LTO. To make use of this with GCC 10, the exported versioned symbols need to be declared explicitly with __attribute__((symver (...))). LLVM/Clang 10 supports symbol versioning with LTO out of the box without any changes needed. Fixes #24.
|
Accidentally closed this. |
zackw
added
enhancement
|
It's not clear to me what still needs to be done here. Off the top of my head, some or all of these may be needed:
What did I miss? |
|
I mistakenly thought PR #109 had already been merged. Further discussion should probably take place there. |
gcc 8.2.0
binutils 2.31.1
glibc 2.28 (with --disable-crypt)
crosscompilation for aarch64, libxcrypt v4.1.1
configure --enable-shared --disable static
If libxcrypt is built with lto in *flags almost all symbols are missing from the library
lto build - bad
Non lto build (gold linker) - good
Is this expected ?
The text was updated successfully, but these errors were encountered: