This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Support binding dysyms to any section
ClosedPublic

Authored by int3 on Jul 2 2020, 3:46 PM.

Details

Reviewers
smeenai
Group Reviewers
Restricted Project
Commits
rG53eb7fda51f2: [lld-macho] Support binding dysyms to any section
Summary

Previously, we only supported binding dysyms to the GOT. This
diff adds support for binding them to any arbitrary section. C++
programs appear to use this, I believe for vtables and type_info.

This diff also makes our bind opcode encoding a bit smarter -- we now
encode just the differences between bindings, which will make things
more compact.

I was initially concerned about the performance overhead of iterating
over these relocations, but it turns out that the number of such
relocations is small. A quick analysis of my llvm-project build
directory showed that < 1.3% out of ~7M relocations are RELOC_UNSIGNED
bindings to symbols (including both dynamic and static symbols).

Diff Detail

Event Timeline

int3 created this revision.Jul 2 2020, 3:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 2 2020, 3:46 PM
int3 updated this revision to Diff 275255.Jul 2 2020, 3:58 PM

update

int3 updated this revision to Diff 275256.Jul 2 2020, 4:02 PM

more const

smeenai added a subscriber: smeenai.Jul 2 2020, 4:59 PM

The approach looks good to me. Once we're able to e.g. self-host and link clang, we can get more accurate numbers and confirm that the overhead of storing all these bindings won't be too high.

lld/MachO/SyntheticSections.cpp
105

Super nit: can we use = initialization instead, for consistency with the rest of the code? (At least, I think = initialization is standard in LLD.)

112

"that dyld to write" -> "that tell dyld to write"?

131–132

Nit: an assert seems more conventional

182–183

We'll initialize e.g. addend to 0 here, and for the GOT entries, the addend is always 0, so the lastBinding.addend != addend condition will never be taken and we won't emit an initial BIND_OPCODE_SET_ADDEND_SLEB. Will dyld assume 0 in that case, or should we initialize it explicitly?

Seems like we were never setting the addend at all before, so maybe assuming dyld will default to 0 is okay? Should probably double-check though.

183

Same nit about = initialization.

184

Are we creating a copy of all the entries here?

185

Is the switch from a range-based for loop only so we have i? If so, I think I'd prefer to just keep a separate offset variable and increment it in a range-based for loop.

Harbormaster failed remote builds in B62777: Diff 275255!
Harbormaster failed remote builds in B62778: Diff 275256!
int3 updated this revision to Diff 275277.Jul 2 2020, 7:57 PM
int3 marked 8 inline comments as done.

address comments

lld/MachO/SyntheticSections.cpp
105

ah yeah I'm just in the habit of using {} normally. will change

182–183

yes I'm pretty sure this is okay. ld64 doesn't emit SET_ADDEND unless we have a non-zero addend.

184

oops

int3 marked 2 inline comments as done.Jul 2 2020, 7:57 PM
smeenai accepted this revision.Jul 2 2020, 8:34 PM

LGTM

lld/MachO/SyntheticSections.cpp
158

Thanks for the comment!

This revision is now accepted and ready to land.Jul 2 2020, 8:34 PM
This revision was automatically updated to reflect the committed changes.