When a constant expr is relative to the constant foo currently being emitted, transform it from the form bar-foo+n to bar-.+m. MC will naively assemble the former version into a subtractor relocation, which isn't always supported, for instance in most ELF platforms. PC-relative relocations with offsets are more widely supported and better tested in most linkers.
Diff Detail
Event Timeline
Hi Joe,
This looks fine on the MachO side. I also tested it with ELF on x86_64 and AArch64, where it fixed the test case you included.
Everything looks good to me, but Rafael and Rui should probably sign off on this, since it touches ELF and COFF too. Rafael, Rui - do you see any problems with this?
- Lang.
This change looks good to me, but I'm not really an owner of this part of the code, so I guess you want to have Rafael take a look.
It seems odd to do this at the asm *printer*
Currently the ELF testcase prints
.long .Lbar-foo
.long .Lbar-foo
And with gas that produces R_X86_64_PC32. In contrast MC produces an error:
Cannot represent a subtraction with a weak symbol.
One of the many horrible things about the .s format is that there is no way to differentiate "this symbol foo" versus "whatever symbol foo resolves to". MC Is trying the second one and failing. Gas is using the first one and finding a relocation that works.
I will take a quick look to see what the change would be like for MC to behave like gas on this one.
Is it possible that a similar issue is impacting MachO?
No worries, thanks for the feedback, Rafael. I was following the example of how we handle rewriting relative references to GOT-equivalent globals into GOTPCREL relocations, which also happens in the AsmPrinter. It'd be great if MC could be made smarter about choosing relocations. The issue also impacts Mach-O, though unlike ELF, Mach-O does support generalized subtractor relocations, so it isn't a showstopper there. These subtractor relocations have however been giving me heartache, exposing unused corners of Darwin's ld and MCJIT, so I think it's better to favor PCREL relocation if we can get them on Mach-O too, since those are much better exercised.
Can confirm that r258329 addresses my use case. Thanks again Rafael. I'll file a separate PR for Mach-O; like I said, it's not a showstopper there.
I will take a quick look to see what the change would be like for MC to behave like gas on this one.
That's a much nicer fix. Thanks Rafael!
Joe - should we close this revision?