This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Have relocation address included in range-check error message
ClosedPublic

Authored by int3 on Feb 3 2022, 6:54 AM.

Details

Summary

This makes it easier to debug those errors. See e.g. https://github.com/llvm/llvm-project/issues/52767#issuecomment-1028713943

We take the approach of 'reverse-engineering' the InputSection from the
output buffer offset. This provides for a cleaner Target API, and is
similar to LLD-ELF's implementation of getErrorPlace().

Diff Detail

Event Timeline

int3 created this revision.Feb 3 2022, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2022, 6:54 AM
int3 requested review of this revision.Feb 3 2022, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2022, 6:54 AM
int3 added inline comments.Feb 3 2022, 6:59 AM
lld/MachO/SyntheticSections.h
597–599

So in LLD-ELF, bufferStart is a member of the Out struct, while the synthetic sections are part of the InStruct. We don't have an Out struct at the moment, but IMO our InStruct should be renamed to Out, for unlike LLD-ELF, our synthetic sections are OutputSections.

Alternatively, we could put all the synthetic sections into a Synth struct, and leave just bufferStart in the Out struct... but I'm not sure what else would go into our Out. Maybe bufferStart could just be a global?

anyway we can figure the exact renaming separately from this diff

Roger added a subscriber: Roger.Feb 25 2022, 12:52 PM
Roger added inline comments.
lld/MachO/Arch/ARM64Common.h
109–112

I'm not sure which way is better. Is there a reason why you didn't use pointer arithmetic here and elsewhere? I'm wondering if the current code performs a dereferencing + address of operations unnecessarily (or if that gets optimized out). It's not a big deal and either way is fine with me but I just wanted to ask.

int3 added inline comments.Feb 25 2022, 12:57 PM
lld/MachO/Arch/ARM64Common.h
109–112

just style preference. This should be trivial for the compiler to optimize, I don't think we have to worry about it (but you can use godbolt to verify)

Roger accepted this revision.Feb 28 2022, 2:42 PM
Roger added inline comments.
lld/MachO/Relocations.cpp
66–67

If calling this function on an offset that doesn't belong to a ConcatOutputSection should not be happening, should we be add an assert to enforce this?

This revision is now accepted and ready to land.Feb 28 2022, 2:42 PM
int3 added inline comments.Feb 28 2022, 6:42 PM
lld/MachO/Relocations.cpp
66–67

yeah fair. I'll just delete this check, the cast<> below itself contains an assert