search for: elfobjectwriter

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a given machine type. The attached patch does s...

+llvmdev On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 10, 2010, at 9:57 AM, Jason Kim wrote: > >> Refactoring the x86 dependent code from ELFObjectWriter class has >> repercussions among several (conflicting) axes of consideration, >> >> 1. namespace pollution - minimize pollution of the llvm:  namespace >> 2. consistency - try to maintain as small a delta between the changes >> 3. linking - minimize the number of addit...

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where Ar...

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" > #include "llvm/Support/DataTypes.h" &gt...

This is a heads up - if you aren't into ELF or ARM, you can stop reading :-) I need to add ARM specific relocation support which require some amount of reorg to the exiting ELFObjectWriter.* to remove x86 biases (or at least move them elsewhere). I am currently working on a set of patches, which I will send to commits for review, hopefully in a day or three. Thanks -jason

...now if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > 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" >>  #include "llvm/Suppo...

...xing. > > On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: >> 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" >>> #...

On Nov 9, 2010, at 9:31 AM, Jason Kim wrote: > This is a heads up - if you aren't into ELF or ARM, you can stop reading :-) > > I need to add ARM specific relocation support which require some > amount of reorg to the exiting ELFObjectWriter.* to remove x86 biases > (or at least move them elsewhere). > I am currently working on a set of patches, which I will send to > commits for review, hopefully in a day or three. Thanks for the heads up, Jason. Looking forward to seeing the patches! -Jim

> 5. I could just add the MBlaze backend specific stuff into ELFObjectWriter > like all of the other backends. > Are their any other opinions on this? I personally prefer all of the MBlaze > backend stuff to be contained inside of lib/Target/MBlaze so that I don't > have to hunt around the LLVM source tree when I'm implementing/fixing the > MBlaze bac...

...wo working architectures we should have a better idea on how > to split it. I can do that. As a note, I just sent another email (before I saw this one) showing how much code was needed to add support for the MBlaze backend. Do you want to take a look at that before I merge the MBlaze stuff into ELFObjectWriter.c? Thanks for reviewing this. -- Wesley Peck University of Kansas SLDG Laboratory

On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > The rest is already in Target, so LGTM :-). Move the > MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from > there. Will do. Again, thank for taking a look at this. -- Wesley Peck University of Kansas SLDG Laboratory

On Fri, Nov 19, 2010 at 12:59 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > >> The rest is already in Target, so LGTM :-). Move the >> MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from >> there. > > Will do. Again, thank for taking a look at this. Heads up: I just lifted some code from X86::RecordRelocation to ELFObjectWriter - More to follow. Thanks, -jason > > -- > Wesley Peck > University of Kansas >...

> Heads up: I just lifted some code from X86::RecordRelocation to > ELFObjectWriter - > More to follow. Thanks, How far do you want to go? I was playing with the idea of factoring the relocation recording into another class and moving those to lib/Target/*. That way the ELF writer becomes non-virtual again. > Thanks, > -jason Cheers, Rafael

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

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

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

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

...hat 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::se...

...// %lo(body_ok) The attached patch makes the following changes to make direct object emitter write out relocations in the correct order: 1. Add a target hook MCELFObjectTargetWriter::ReorderRelocs. The default behavior sorts the relocations by the r_offset. 2. Move struct ELFRelocationEntry from ELFObjectWriter to MCELFObjectTargetWriter and add member fixup to it. The overridden version of ReorderRelocs (MipsELFObjectWriter::ReorderRelocs) needs access to ELFRelocationEntry::Type and MCFixup::Value to reorder the relocations. Do you think these changes are acceptable? On Wed, Mar 21, 2012 at 3:50 PM, J...

...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, r...