[LLVMdev] Target Assembly Parser: Access to Reloc::Model

[Rafael Espíndola]

Would just adding a getRelocM to MCObjectFileInfo solve your problem?

On 27 February 2014 07:17, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote:
> 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
>
> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: 26 February 2014 23:24
> To: Matheus Almeida
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Target Assembly Parser: Access to Reloc::Model
>
> 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
>
>
> On 25 February 2014 11:31, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote:
>> 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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>