This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Handle user-provided dtrace symbols to avoid linking failure
ClosedPublic

Authored by PRESIDENT810 on Jul 4 2022, 12:55 AM.

Details

Summary

This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed.

I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h.

Diff Detail

Event Timeline

PRESIDENT810 created this revision.Jul 4 2022, 12:55 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJul 4 2022, 12:55 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a subscriber: mgorny. · View Herald Transcript
PRESIDENT810 requested review of this revision.Jul 4 2022, 12:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 4 2022, 12:55 AM
int3 added a comment.Jul 5 2022, 12:55 PM

Thanks for working on this!

I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h.

I'm not aware of anyone asking for this right now, but it does seem like something we'll want eventually :) feel free to work on that in a followup if you're interested

lld/MachO/Arch/ARM.cpp
177–178

let's include a comment about how this only implements -no_dtrace_dof, and that this deviates from ld64's default behavior

184

I don't think we should make direct references to ld64 code like this

204–206

code convention is to omit braces for one-liners

224

nit: can you set your editor to include newlines at EOF?

lld/MachO/Arch/ARM64Common.cpp
117–121

we should handle this generically in validateRelocationInfo (if we aren't doing that already) rather than here

lld/MachO/Dtrace.cpp
1–2

nit: fix formatting

17
18

could use startswith()

24–40

not sure this function is necessary. Couldn't we hoist the error() into TargetInfo::handleDtraceReloc and call that directly?

lld/test/MachO/arm-dtrace.ll
35–61

can we minimize the test case? probably most of the instructions aside from the calls to dtrace functions can be removed. The !srcloc references too

BertalanD added inline comments.
lld/MachO/Arch/X86_64.cpp
222
lld/MachO/Dtrace.cpp
17–22

It looks like this function might be quite hot. Do you think it would make sense for it to be an inline function in the header file?

lld/test/MachO/arm-dtrace.ll
1

llvm-as can only be run for this test case if the ARM backend is enabled.

lld/test/MachO/arm64-32-dtrace.ll
1
lld/test/MachO/arm64-dtrace.ll
1
lld/test/MachO/x86_64-dtrace.ll
1
BertalanD added inline comments.Jul 5 2022, 1:15 PM
lld/MachO/Arch/X86_64.cpp
222

or even loc[-1] would work, I guess

int3 added a comment.Jul 5 2022, 2:16 PM

Actually, is there any reason the test cases need to be in bitcode rather than assembly? In general we should prefer assembly if we are not testing things that require LTO

int3 added inline comments.Jul 5 2022, 8:29 PM
lld/MachO/Dtrace.cpp
17–22

Agreed. In fact we could take it one step further though and eliminate the function entirely... the call to this can just be replaced by name.startswith("___dtrace_").

Remove some unnecessary code. Add comment for handleDtraceReloc function. Replace IR tests with assembly tests.

oontvoo added inline comments.Jul 6 2022, 6:29 AM
lld/MachO/Arch/ARM.cpp
44

Let's not copy the reloc.

177
179

why do we need this assert if the default in the following switch already handles the checking?

187

these magic numbers are a bit unfortunate ... i wonder if it's better to use constants?

209

consider using toString(Symbol*) instead. (That way, we get the demangled vs non-demangled handling for the symbol name, depending on whether -demangle is set)

lld/MachO/Arch/ARM64Common.h
33
lld/MachO/Arch/X86_64.cpp
42

Pass reloc by reference instead of by value. Remove the unnecessary assertion. Use toString(Symbol *) instead of getName().

I'm not sure about the magic number part. ld64 just uses these numbers directly to overwrite the original instructions, and they are not actually "magic numbers", but rather assembly instructions corresponding to different architectures, I think? Also, the comments above could give illustrations about what assembly instructions these numbers represent. So I'm not very certain if it's necessary to use constants instead.

int3 added a comment.Jul 6 2022, 11:52 AM

Just some nits but otherwise lgtm :)

lld/MachO/Arch/ARM.cpp
182–183

could we hoist this to the top of the function? seems like we'd just never want to modify any dtrace refs if we are outputting an object file

lld/MachO/Arch/X86_64.cpp
210–213

I kinda preferred the previous version where you used write32le here. I think @BertalanD's suggestion of writing to loc[-1] was to make it clear that we are only modifying a single byte. But if we're emitting a 4-byte instruction, write32le() makes sense

i.e. I'm suggesting

loc[-1] = 0x90;
write32le(loc, 0x00401F0F);
lld/test/MachO/arm-dtrace.s
5 ↗(On Diff #442574)

are the -demangle -dynamic flags actually necessary? Also, %lld by default specifies a platform version of 11.0. Any reason we can't use that default?

30–31 ↗(On Diff #442574)

are these branching instructions necessary? doesn't seem like they really test anything

lld/test/MachO/x86_64-dtrace.s
10–16 ↗(On Diff #442574)

nit: can we column-align the right hand side?

Update according to int3's advice.

int3 accepted this revision.Jul 7 2022, 10:18 AM

lgtm, thanks! Do you have commit permissions or do you need me to land this for you?

This revision is now accepted and ready to land.Jul 7 2022, 10:18 AM

lgtm, thanks! Do you have commit permissions or do you need me to land this for you?

I actually don't commit access so please help me land this. Please use "Kaining Zhong <zhongkaining.paxos@bytedance.com>" if any author info is needed. Thanks!

This revision was landed with ongoing or failed builds.Jul 11 2022, 12:32 PM
This revision was automatically updated to reflect the committed changes.