llvm dev - Dec 2012 - [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

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>

On Tue, Dec 11, 2012 at 2:48 PM, Carter, Jack <jcarter at mips.com>
wrote:
> Attached are the promised patches for the below proposed change.
>
Just a quick question from an initial review: isn't the int->bool
mapping of flags a bit limiting. Flag can have actual values and not
only be there or not be there. Wouldn't a more generic mapping
(string->string ?) be more universally useful? Or am I missing
something obvious here...

Eli