Target Assembly Parser: Access to Reloc::Model

Some Mips macros (e.g. la[1]) and the handling of Mips directives used for Position-Independent Programming (e.g. .cpload[2]) require access to Reloc::Model from within the Assembly Parser but there doesn’t seem to be a way to do it in its current form.

  1. Reloc::Model is passed to MCObjectFileInfo but it’s a private member of that class

  2. TargetMachine is not accessible

I can also see that clang initializes MCObjectFileInfo with Reloc::Default which isn’t entirely right but that’s a different matter. I’ll come back to that later after we decide what’s the right approach to fix this issue.

Any suggestions about the right way to expose the relocation model to the assembly parser ?

[1] la – load address. Roughly speaking this macro expands to a GOT access if generating PIC or to an absolute access if not .

[2] .cpload – This directive sets up $gp (Global Pointer) if PIC or it can be ignored for the static model.

Regards,

Matheus

Can't this be handled in the Streamer? That way the asm streamer can
just print "la" and ".cpload" and the object streamer already has the
necessary information.

Cheers,
Rafael

Hi Rafael,

Sure, the expansion of at least .cpload should be done in the Target ELFStreamer but AFAICS it doesn't solve my initial problem. MCCodeGenInfo is not created in tools where CodeGen isn't needed (llvm-mc) and it's still not possible to access the Relocation Model in MCObjectFileInfo from the target streamer (private member).

Am I missing something obvious ?

There are many ways to work around this issue (some better than others though...):
1) Store Reloc::Model in MCSubtargetInfo.
2) Make MCCodeGenInfo accessible from both worlds (CodeGen and all of the MC layer).
3) Pass Reloc::Model to the Assembly Parser. This could then be passed on to the streamers without problems because the AsmPrinter also has access to the relocation model.
4) Use 'friendship' to allow the streamers to access the private members of MCObjectFileInfo.

Regards,
Matheus

Would just adding a getRelocM to MCObjectFileInfo solve your problem?

Yes, that works for me.
This is a trivial fix but I'll submit a patch anyway for review.

Regards,
Matheus