This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Add -Bno-symbolic
ClosedPublic

Authored by MaskRay on May 12 2021, 10:02 PM.

Details

Summary

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.

Diff Detail

Event Timeline

MaskRay created this revision.May 12 2021, 10:02 PM
MaskRay requested review of this revision.May 12 2021, 10:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2021, 10:02 PM

(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.)

jhenderson added inline comments.May 13 2021, 12:32 AM
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.

MaskRay updated this revision to Diff 345184.May 13 2021, 9:28 AM
MaskRay marked an inline comment as done.

add a release note

MaskRay added inline comments.May 13 2021, 9:38 AM
lld/ELF/Driver.cpp
956–963

Yes. Added

MaskRay added a comment.EditedMay 13 2021, 9:18 PM

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:)

jhenderson accepted this revision.May 14 2021, 1:13 AM

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.

This revision is now accepted and ready to land.May 14 2021, 1:13 AM

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.

Oh, I missed D102461, combined with a misreading of the test coverage. LGTM!

peter.smith accepted this revision.May 14 2021, 2:01 AM

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.

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.)

This revision was automatically updated to reflect the committed changes.