This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Add -Bsymbolic-non-weak
ClosedPublic

Authored by smeenai on Aug 18 2023, 3:51 PM.

Details

Summary

This adds a new -Bsymbolic option that directly binds all non-weak
symbols. There's a couple of reasons motivating this:

  • The new flag will match the default behavior on Mach-O, so you can get consistent behavior across platforms.
  • We have use cases for which making weak data preemptible is useful, but we don't want to pessimize access to non-weak data. (For a large internal app, we measured 2000+ data symbols whose accesses would be unnecessarily pessimized by -Bsymbolic-functions.)

Diff Detail

Event Timeline

smeenai created this revision.Aug 18 2023, 3:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2023, 3:51 PM
smeenai requested review of this revision.Aug 18 2023, 3:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2023, 3:51 PM

Glad to know see more adoption of the -Bsymbolic-non-weak* idea:) (https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic)

We have use cases for which making weak data preemptible is useful, but we don't want to pessimize access to non-weak data. (For a large internal app, we measured 2000+ data symbols whose accesses would be unnecessarily pessimized by -Bsymbolic-functions.)

The main problem is copy relocations, which is incompatible with making non-weak data non-preemptible.
Are you able to rule out all copy relocations (default ELF codegen for -fno-pic)?

MaskRay accepted this revision.Aug 18 2023, 4:20 PM
This revision is now accepted and ready to land.Aug 18 2023, 4:20 PM

Glad to know see more adoption of the -Bsymbolic-non-weak* idea:) (https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic)

Yup :) It seems like the nicest solution for maintaining preemptibility in the small amount of cases which need it while not unnecessarily slowing down everything else.

We have use cases for which making weak data preemptible is useful, but we don't want to pessimize access to non-weak data. (For a large internal app, we measured 2000+ data symbols whose accesses would be unnecessarily pessimized by -Bsymbolic-functions.)

The main problem is copy relocations, which is incompatible with making non-weak data non-preemptible.
Are you able to rule out all copy relocations (default ELF codegen for -fno-pic)?

Thankfully yes, because we build everything as PIC/PIE (and IIRC modern Android versions require PIE).

Update docs/ld.lld.1 as well

smeenai updated this revision to Diff 551900.Aug 20 2023, 10:23 PM

Update ld.lld.1

MaskRay accepted this revision.Aug 20 2023, 10:24 PM

Update docs/ld.lld.1 as well

How do you verify the output? I used groff -man -T html and the result looked reasonable, but also pretty different from things like https://man.archlinux.org/man/extra/lld/ld.lld.1.en, so I was wondering what people usually do.

Update docs/ld.lld.1 as well

How do you verify the output? I used groff -man -T html and the result looked reasonable, but also pretty different from things like https://man.archlinux.org/man/extra/lld/ld.lld.1.en, so I was wondering what people usually do.

I just use man docs/ld.lld.1 and check whether it looks good...

Update docs/ld.lld.1 as well

How do you verify the output? I used groff -man -T html and the result looked reasonable, but also pretty different from things like https://man.archlinux.org/man/extra/lld/ld.lld.1.en, so I was wondering what people usually do.

I just use man docs/ld.lld.1 and check whether it looks good...

Ah, that's much simpler, thanks.

This revision was automatically updated to reflect the committed changes.