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
- Repository
- rL LLVM
Event Timeline
LGTM
test/CodeGen/SPARC/obj-relocs.ll | ||
---|---|---|
1 ↗ | (On Diff #27674) | 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 ↗ | (On Diff #27674) | 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