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

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.

Remember, this issue is not whether the direct or standalone assembler can deal
with it in their code. The problem is how to convey it to the
<target>ELFObjectWriter in a clean manor because both use it. Some flags
are picked by being the default, some from the commandline and others from the
run of play. It is not a difficult issue except we require the ELF portion to
work from the same sketch book for the 2 assemblers.

I am experimenting putting in a std::set into the MCSubtargetInfo base class
that is for target use and see if I can end my ordeal ;-) Probably only useful
for the older targets which have a lot of baggage to support. If that works I
can convert it to work with Feature, but that is a bit of overkill at this
point.

Cheers,

Jack
________________________________________
From: Rafael Espíndola [rafael.espindola at gmail.com]
Sent: Friday, December 07, 2012 1:52 PM
To: Carter, Jack
Cc: List
Subject: Re: [LLVMdev] [MC] [llvm-mc] Getting target specific information to
<target>ELFObjectWriter

On 6 December 2012 17:49, Carter, Jack <jcarter at mips.com>
wrote:
> Older targets like Mips had/have assemblers and ABIs that carry a lot of
> baggage.
>
> The small bit of baggage that is giving me fits is that MipsELFObjectWriter
> needs to know the relocation model (static,pic,cpic), whether we are using
> xgot (-mgot), which abi (old,new), which architecture (32r[123],64[123]),
> which if any coprocessor or extention instructions are used
> (mips16,micromips,etc.).
So the mips assembler has command line options like -fPIC?

Cheers,
Rafael

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

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 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