<div dir="ltr">VK_Sparc_GOT22, VK_Sparc_PC22, and VK_Sparc_HI all print as "%hi(name)", so you can't tell which one was going to be emitted in a .o by looking at the assembly -- and llvm could've gotten it wrong without it showing in the asm. At parse time, the asm parser has to choose which relocation type to turn that ambiguous expression back into.<div><br><div><span style="font-size:12.8000001907349px">Of course it's stupid that they all share the same assembly syntax, but...</span><div class="" style="font-size:12.8000001907349px"></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 7:33 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> Could this be changed to used llvm-mc? If not, what asm parsing feature that is missing?<br>
>><br>
>> It can be done in another commit, but we should get to it.<br>
> 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.<br>
<br>
</span>How? If it prints the correct assembly (and we have a test for that)<br>
and the correct assembly produces the correct .o (and we have a test<br>
for that), what code path is missed that has a bug when producing a .o<br>
directly?<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>