This is an archive of the discontinued LLVM Phabricator instance.

[SPARC] Repair GOT references to internal symbols.
ClosedPublic

Authored by jyknight on Jun 15 2015, 8:10 AM.

Details

Summary

They had been getting emitted as a section + offset reference, which
is bogus since the value needs to be the offset within the GOT, not
the actual address of the symbol's object.

Diff Detail

Event Timeline

jyknight updated this revision to Diff 27674.Jun 15 2015, 8:10 AM
jyknight retitled this revision from to [SPARC] Repair GOT references to internal symbols..
jyknight updated this object.
jyknight edited the test plan for this revision. (Show Details)
jyknight added a subscriber: Unknown Object (MLST).
rafael accepted this revision.Jun 17 2015, 6:56 AM
rafael added a reviewer: rafael.
rafael added a subscriber: rafael.

LGTM

test/CodeGen/SPARC/obj-relocs.ll
1

Could this be changed to used llvm-mc? If not, what asm parsing feature that is missing?

It can be done in another commit, but we should get to it.

This revision is now accepted and ready to land.Jun 17 2015, 6:56 AM
jyknight added inline comments.Jun 17 2015, 7:08 PM
test/CodeGen/SPARC/obj-relocs.ll
1

llvm-mc is tested in the other test case changed here. But, having a case for directly emitting relocs separate from going through textual asm is valuable, at the least because the "%hi" asm directive can parse into 3 different relocation types, depending on context. It'd be entirely plausible to have a bug that outputs an incorrect relocation in direct object writing, but have it turn out right after going through asm serialization/parsing.

Could this be changed to used llvm-mc? If not, what asm parsing feature that is missing?

It can be done in another commit, but we should get to it.

llvm-mc is tested in the other test case changed here. But, having a case for directly emitting relocs separate from going through textual asm is valuable, at the least because the "%hi" asm directive can parse into 3 different relocation types, depending on context. It'd be entirely plausible to have a bug that outputs an incorrect relocation in direct object writing, but have it turn out right after going through asm serialization/parsing.

How? If it prints the correct assembly (and we have a test for that)
and the correct assembly produces the correct .o (and we have a test
for that), what code path is missed that has a bug when producing a .o
directly?

Cheers,
Rafael

This revision was automatically updated to reflect the committed changes.