similar to: [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

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)

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

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

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 >

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

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

Eli, Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers. Working with the current framework it seemed the least disruptive. I'll describe the problem again. The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object

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

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

I'm trying to form contingincy tables among a set of character variables which were read from a .csv file and have missing represented as "". I want to exclude the missing levels from the table. > levels(CPIC) [1] "" "N" "Y" > levels(Manix) [1] "" "N" "Y" > xtabs(~CPIC + Manix, exclude=c("",NA))

So what I am hearing is that I should add the following to MC/MCFixup.h: FK_GPRel_1, ///< A one-byte pc relative fixup. FK_GPRel_2, ///< A two-byte pc relative fixup. FK_GPRel_4, ///< A four-byte pc relative fixup. FK_GPRel_8, ///< A eight-byte pc relative fixup. In MC/MCStreamer.cpp MCStreamer::EmitGpRel32Value() Figure out how to mark it with the imprint of

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that

Hi Akira, If I follow correctly, the relocation entries can thus be in a different order than the instructions that they're for? That seems a bit odd, but I suppose there's nothing inherently wrong with that. It's just not something, AFAIK, that llvm has had to deal with before. This should definitely be a target-specific thing, not a general ELFObjectWriter thing, as other targets

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for

What would be the best way to sort relocation entries before they are written out in ELFObjectWriter::WriteRelocationsFragment? According to the Mips ABI documents I have, there are certain restrictions on the order relocations appear in the table (e.g. R_MIPS_HI16 and R_MIPS_GOT16 must be followed immediately by a R_MIPS_LO16). When I enable post RA scheduling, some of the restrictions are

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For