Page MenuHomePhabricator

[WIP][mips] Use pc-relative relocations in .eh_frame
AcceptedPublic

Authored by atanasyan on May 21 2020, 11:13 AM.

Details

Summary

Use pc-relative relocations in .eh_frame. R_MIPS_PC32 relocation is generated in 32-bit case. R_MIPS_PC32 | R_MIPS_64 relocation chain is generated in 64-bit case for all code model.

With this change object files can be linked by LLD without having to pass -Wl,-z,notext options.

Now this patch is rather "proof-of-concept". Not a commit ready changes. Any comments are welcome.

Diff Detail

Event Timeline

atanasyan created this revision.May 21 2020, 11:13 AM
Herald added a project: Restricted Project. · View Herald Transcript

I cannot select default behaviour for the LLVM in case of generating .eh_frame sections for MIPS:

  1. Unconditionally use pc-relative relocations.
  2. Use pc-relative relocations by default, but provide options for switching to absolute relocations.
  3. Use absolute relocations by default, but provide options for switching to pc-relative relocations.

I prefer the second variant. Any comments?

Hiya,

I'd probably also go for 2 also as the default, as long as its configurable then just a sensible default is good

Thanks

FYI, I backported this and the other diff to llvm 10 and its all working nicely, now building all packages with lld without issue

Thanks!

MaskRay accepted this revision.Jul 28 2020, 7:57 AM

LGTM.

This revision is now accepted and ready to land.Jul 28 2020, 7:57 AM
arichardson accepted this revision.Nov 4 2020, 12:32 PM

Hi guys,

any chance of this making it into 11.1.0 or 12?

Hi,

Hi guys,

any chance of this making it into 11.1.0 or 12?

This task was out of my scope for a while. As far as I remember there were some problems with test cases. One more thing - I couldn't figure out how to enable/disable this functionality by clang command line options. MCObjectFileInfo and TargetLoweringObjectFileELF classes are far away from any target related context/settings. I do not think that this change (especially without any "disable" functionality) is a good candidate for 11.1.0 or 12 releases. But I will try to push it to the main branch soon. I'm sorry for the delay.

No worries - whenever you have time!