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

Carter, Jack jcarter at mips.com
Tue Dec 11 14:48:45 PST 2012 

Attached are the promised patches for the below proposed change.

Cheers,

Jack
________________________________________
From: Carter, Jack
Sent: Tuesday, December 11, 2012 1:33 PM
To: Jim Grosbach
Cc: Rafael Espíndola; List
Subject: RE: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

Jim,

You are correct: MipsSubtarget.

For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo.

The patch I hope to send out for review will do this:

Add a new data member to MCSubtargetInfo base class. It will be a set of integers that is used or not by targets to post flags that otherwise cannot be stored equally by both the llc and llvm-mc use of MCSubtargetInfo.

MCSubtargetInfo reference will be passed to the create<target>AsmBackend() method that passes it to createObjectWriter().

For most of the flags that will be added to the MCSubtargetInfo object for llc would be set during the construction of MipsSubtarget. For llvm-mc, most of the flags would be set during the <target>AsmParser construction. I say most, because some flags may be set during the run of play such as through assembler directives.

All flag types would be target specific. I define my enumerated list in MipsMCTargetDesc.h.

After this change, any target specific ELF header changes should not affect any files above the llvm/lib/Target/<target> level with the possible exception of llvm/include/llvm/Support/ELF.h.

I'll send out the patch later today. I am not wedded to it, but need a solution.

Jack
________________________________________
From: Jim Grosbach [grosbach at apple.com]
Sent: Monday, December 10, 2012 4:25 PM
To: Carter, Jack
Cc: Rafael Espíndola; List
Subject: Re: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: elf_header.patch
Type: text/x-patch
Size: 28647 bytes
Desc: elf_header.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/67d32afc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elf_header_clang.patch
Type: text/x-patch
Size: 1632 bytes
Desc: elf_header_clang.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/67d32afc/attachment-0001.bin>

More information about the llvm-dev mailing list