This option will be available in GNU ld 2.27 (https://sourceware.org/bugzilla/show_bug.cgi?id=27834).
This option can cancel previously specified -Bsymbolic and
-Bsymbolic-functions. This is useful for excluding some links when the
default uses -Bsymbolic-functions.
Details
- Reviewers
grimar jhenderson peter.smith - Commits
- rG4adf7a760406: [ELF] Add -Bno-symbolic
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
(I know our -Bsymbolic-functions tests are insufficient, e.g. its effect on data symbols and its interaction with -Bsymbolic is untested. I may add tests in a separate patch.)
lld/ELF/Driver.cpp | ||
---|---|---|
956–963 | If I'm reading this change correctly, there is a change in behaviour for the case where both -Bsymbolic and -Bsymbolic-functions are specified. Previously, both config variables would be set and since -Bsymbolic-functions is a subset of -Bsymbolic, it would behave the same as -Bsymbolic. Now, if the arguments were ordered -Bsymbolic -Bsymbolic-functions, only the config->bsymbolicFunctions variable would be set, and consequently we'd see a behaviour change. Is this intentional? It's fine, if that's what GNU does, but it probably deserves a release note. |
lld/ELF/Driver.cpp | ||
---|---|---|
956–963 | Yes. Added |
I hope that Linux distributions can make better use of -Bsymbolic-functions to fix a technical fallout for ELF dynamic linking. -fno-pic should be fixed to use GOT: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Perhaps it needs 5 or even 10 years to shift to the better world but they will need -Bno-symbolic sooner or later:)
You said that -Bsymbolic-functions is undertested, so I assume the behaviour of "last one wins" for -Bsymbolic-functions + -Bsymbolic will be covered by that work? If so, LGTM. If not, I think you should expand the bsymbolic.s input such that -Bsymbolic and -Bsymbolic-functions output looks different somehow.
LGTM too.
As an aside, is it worth attempting something like "-warn-backrefs", say "-warn-interposition" for executables. In that case we know the definitions of the executable and all the shared libraries as well as the DT_NEEDED order. We could do something like:
"Warning symbol S of type STT_FUNC is defined in executable A and shared objects B and C, using definition in A.". There would be limitations within LLD as we don't keep much more than the symbol table of shared objects, and it might not know all the shared objects being loaded. There is a possibility of optionally doing more such as loading the dynamic section to check if DF_SYMBOLIC is set, this would permit "Warning symbol S is defined in executable A and shared object B with DF_SYMBOLIC flag. A and B will use different definitions."
Nothing stopping this being an external tool although having it built into the linker makes it easier to use.
This is a good idea. Similar to archive shadowing, if the linker command line contains ... a.so b.so ... and we know that not all b.so definitions are provided by previous DSOs or the executable, there is a potential interposition risk.
(As of DF_SYMBOLIC, it would be really difficult to eliminate copy relocations so -Bsymbolic might be impractical for a long time.)
If I'm reading this change correctly, there is a change in behaviour for the case where both -Bsymbolic and -Bsymbolic-functions are specified. Previously, both config variables would be set and since -Bsymbolic-functions is a subset of -Bsymbolic, it would behave the same as -Bsymbolic. Now, if the arguments were ordered -Bsymbolic -Bsymbolic-functions, only the config->bsymbolicFunctions variable would be set, and consequently we'd see a behaviour change.
Is this intentional? It's fine, if that's what GNU does, but it probably deserves a release note.