<div dir="ltr"><div>Hi Alex,</div><div><br></div><div>thanks a lot for the explanation. I think I now better understand the reason. I will look into the VariantKind and the MachineOperands to convey the needed information to to the MCCodeEmitter.<br></div><div><br></div><div>Kind regards,<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-10 22:26 GMT+02:00 Alex Bradbury <span dir="ltr"><<a href="mailto:asb@lowrisc.org" target="_blank">asb@lowrisc.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10 July 2018 at 17:51, Roger Ferrer Ibáñez via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> H all,<br>
><br>
> I'm looking at generating PIC code for RISC-V in the context of Linux. Not<br>
> sure if anyone is working on this already, any inputs are very welcome.<br>
<br>
</span>Great, that would be a useful contribution.<br>
<span class=""><br>
> I'm now looking at function calls which in the RISCV backend are represented<br>
> via two pseudoinstructions RISCV::TAIL and RISCV::CALL.<br>
><br>
> Currently those pseudos are lowered in MCCodeEmitter. They are expanded into<br>
> AUIPC and JALR instructions and the first one needs a relocation, which for<br>
> a static reloc model is R_RISCV_CALL but for PIC code should be<br>
> R_RISCV_CALL_PLT.<br>
><br>
> The problem I find is that at this point it is too late to tell the exact<br>
> relocation needed: as far as I can tell there is no way to determine the<br>
> relocation model. Perhaps this is on purpose and the MCCodeEmitter should<br>
> not have that knowledge. Or maybe not and it is just a matter to "push" a<br>
> TargetMachine to it, but the way the class is constructed does not look like<br>
> this approach is workable.<br>
><br>
> So I was considering lowering these pseudo-instructions in AsmPrinter<br>
> instead. There I can tell the exact kind of the MCOperand I want thanks to<br>
> the fact that the AsmPrinter is constructed with a TargetMachine.<br>
><br>
> That said perhaps there are extra constraints that require doing the<br>
> lowering in MCCodeEmitter, unfortunately I can't tell exactly what is the<br>
> advantage of lowering that late.<br>
<br>
</span>As there is no way of generating an R_RISCV_CALL relocation in<br>
assembly other than using the call pseudoinstruction, the desire is<br>
that you can produce an ELF with that relocation regardless of whether<br>
you emit .s and then assemble it or emit the .o directly. This pushes<br>
you towards lowering at rather a late stage. There may be better ways<br>
of structuring the current logic to achieve that aim of course.<br>
<span class=""><br>
> Alternatively I was considering adding two new pseudos like RISCV::CALL_PLT<br>
> and RISCV::TAIL_PLT and also lower them at MCCodeEmitter. But this looks a<br>
> bit too bulky to me and I think I would still have the issue that the "call"<br>
> and "tail" pseudos in the assembler would need some extra magic (i.e. when<br>
> assembling a "call" pseudoinstruction with -fPIC) so they don't end being<br>
> parsed as the non-PIC counterparts. I might be wrong here though.<br>
<br>
</span>As Eli suggests, using the same instruction with different VariantKind<br>
and/or MachineOperand flags would be the right way to go. It seems<br>
that `call foo` in binutils gas always produces an R_RISCV_CALL<br>
relocation while `call foo@plt` will produce R_RISCV_CALL_PLT.<br>
<br>
Best,<br>
<br>
Alex<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Roger Ferrer Ibáñez<br></div>
</div>