[LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

[Jim Grosbach]

On Dec 10, 2012, at 1:15 PM, "Carter, Jack" <jcarter at mips.com> wrote:

> Here are some examples using the gnu assembler reacting to the same input file with different commandline options.
> 
> These are using the GCC assembler on hello.c
> // abi o32, arch mips32r2, relocation model pic+cpic
> mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s 
> e_flags             0x70001007  EF_MIPS_NOREORDER EF_MIPS_PIC EF_MIPS_CPIC E_MIPS_ABI_O32  EF_MIPS_ARCH_32R2 
> 
> // abi o32, arch mips32r2, relocation model cpic
> mips-linux-gnu-as -mips32r2 -EL -call_nonpic -o hello_gas.o hello_gas.s
> e_flags             0x70001005  EF_MIPS_NOREORDER EF_MIPS_CPIC E_MIPS_ABI_O32  EF_MIPS_ARCH_32R2 
> 
> // abi o32, arch mips32r2, relocation model non-shared (not pic or cpic)
> mips-linux-gnu-as -mips32r2 -EL -non_shared -o hello_gas.o hello_gas.s
> e_flags             0x70001001  EF_MIPS_NOREORDER E_MIPS_ABI_O32 EF_MIPS_ARCH_32R2 
> 
> // abi n32, arch mips3, relocation model non-shared
> mips-linux-gnu-as -mips3 -EL -non_shared -n32 -o hello_gas.o hello_gas.s
> e_flags             0x20000021  EF_MIPS_NOREORDER EF_MIPS_ABI2  EF_MIPS_ARCH_3 
> 
> I dumped these with my own dumper, but you can do it with "readelf -h".
> 
> The issue goes beyond the commandline though. The real issue is that <target>ELFObjectWriter is used by both the integrated assembler as well as the standalone one. But the 2 gather information that ends up in the ELF header in different ways such as assembler directives in the standalone assembler such as ".options pic0" which forces non-shared relocation model. 
> 
> The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. 

I don't see a definition of a MipsSubtargetInfo class in the tree. Do you mean MipsSubtarget as defined in MipsSubtarget.h?

-Jim

> 
> I am open to better suggestions as long as it solves the basic issue and allows me to mark up ELF header information with fungible target specific information without affecting other targets going forward.
> 
> Cheers,
> 
> Jack
> 
> ________________________________________
> From: Rafael Espíndola [rafael.espindola at gmail.com]
> Sent: Saturday, December 08, 2012 10:42 AM
> To: Carter, Jack
> Cc: List
> Subject: Re: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter
> 
> On 7 December 2012 18:57, Carter, Jack <jcarter at mips.com> wrote:
>> Hi Rafael,
>> 
>> There are a lot of flags. Here are the ones you ask about:
>> 
>> -KPIC, -call_shared     generate SVR4 position independent code
>> -call_nonpic            generate non-PIC code that can operate with DSOs
>> -mvxworks-pic   generate VxWorks position independent code
>> -non_shared             do not generate code that can operate with DSOs
>> -xgot                   assume a 32 bit GOT
>> 
>> Just to make things fun, the SGI notion of cpic (call pic) fits gnu's -call_nonpic.
> 
> Awesome. As a though exercise I would suggest forgetting for the
> moment that llvm even has a codegen module. Just pick one of the above
> options and an example .s where it changes the output and then make
> llvm-mc do the same.
> 
> Without knowing what the options do it is hard to guess what the best
> change would be, but a first try would be extending
> MCELFObjectTargetWriter.
> 
> Can you post an example of a .s where one of the above options makes a
> difference? I.E., can you write a test that should pass once the
> option is implemented in llvm-mc? Having a concrete example should
> make it easier to discuss.
> 
>> Cheers,
>> 
>> Jack
>> 
> 
> Cheers,
> Rafael
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev