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.
Details
Diff Detail
Event Timeline
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. |
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
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.