search for: mcelfobjecttargetwrit

...riter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" > #include "llvm/Support/DataTypes.h" > #include "llvm/Support/ELF.h" > +#include <vector> > > namespace llvm { > class MCELFObjectTargetWriter { > @@ -27,6 +28,33 @@ protected: > uint16_t EMachine_, bool HasRelocationAddend_); > > public: > + /// @name Relocation Data > + /// @{ > + > + struct ELFRelocationEntry { > + // Make these big enough for both 32-bit and 64-bit >...

...m/MC/MCELFObjectWriter.h >> @@ -13,6 +13,7 @@ >>  #include "llvm/MC/MCObjectWriter.h" >>  #include "llvm/Support/DataTypes.h" >>  #include "llvm/Support/ELF.h" >> +#include <vector> >> >>  namespace llvm { >>  class MCELFObjectTargetWriter { >> @@ -27,6 +28,33 @@ protected: >>                            uint16_t EMachine_,  bool HasRelocationAddend_); >> >>  public: >> +  /// @name Relocation Data >> +  /// @{ >> + >> +  struct ELFRelocationEntry { >> +    // Make these big enou...

...> @@ -13,6 +13,7 @@ >>> #include "llvm/MC/MCObjectWriter.h" >>> #include "llvm/Support/DataTypes.h" >>> #include "llvm/Support/ELF.h" >>> +#include <vector> >>> >>> namespace llvm { >>> class MCELFObjectTargetWriter { >>> @@ -27,6 +28,33 @@ protected: >>> uint16_t EMachine_, bool HasRelocationAddend_); >>> >>> public: >>> + /// @name Relocation Data >>> + /// @{ >>> + >>> + struct ELFRelocationEntry { &gt...

...09 R_MIPS_GOT16      00000000   .bss // %got(body_ok) > 00000754  00000406 R_MIPS_LO16       00000000   .bss // %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 > acc...

...%lo(scope_top) 0000074c 00000409 R_MIPS_GOT16 00000000 .bss // %got(body_ok) 00000754 00000406 R_MIPS_LO16 00000000 .bss // %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...

...ntly unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding to use. As far as I can determine by source examination and judicious use of a debugger there isn't a simple path from the command line and the setting of ABIname in MCTargetOptions to where an instance of a subclass of MCELFObjectTargetWriter is created....

...n, I decided to take an approach that seems simpler than yours, as I'm only trying to solve my own problem. It relies on having things lower in the MC layer be able to query MCTargetOptions. This is my plan: Make a path from the callers of Target::createAsmBackend to get MCTargetOptions to the MCELFObjectTargetWriter subclass or some method in the creation chain: <client, e.g. llvm-mc> -> Target::createAsmBackend(..., MCTargetOptions) -> (*MCAsmBackendCtorFn)(..., MCTargetOptions) -> <MCAsmBackend subclass constructor wanting options>(..., MCTargetOptions) adds MCT...

...thing, not a general ELFObjectWriter thing, as other targets may have entirely different needs. Offhand, it seems reasonable to have a post-processing pass over the relocation list before it's written out to the file. The target can manipulate the list in whatever manner it needs to. A hook on MCELFObjectTargetWriter should do the trick. -Jim On Mar 19, 2012, at 1:39 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > 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...

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

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

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

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)

...lvm 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, >> >&gt...

...experience with some class names that really imply the wrong hierarchical relationships. // Doesn't start off too badly. MCObjectWriter ELFObjectWriter MachObjectWriter // But no [Win]COFFObjectWriter (don't expect you to change that!) // Then we get to the target-specific bits... MCELFObjectTargetWriter <arch>ELFObjectWriter // <arch> = X86, MBlaze, ARM, Mips, PPC // Note the subclasses do not have "Target" in the name. // Which makes them look like subclasses of ELFObjectWriter. // And now a special special case. MCWinCOFFObjectTargetWriter // in MCWinCOFFObjectWriter...

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

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

...mer.cpp for Release+Asserts build llvm[2]: Compiling MCDwarf.cpp for Release+Asserts build llvm[2]: Compiling SymbolSize.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugLoc.cpp for Release+Asserts build llvm[2]: Compiling LiveStackAnalysis.cpp for Release+Asserts build llvm[2]: Compiling MCELFObjectTargetWriter.cpp for Release+Asserts build llvm[2]: Compiling SymbolicFile.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugRangeList.cpp for Release+Asserts build llvm[2]: Compiling MCELFStreamer.cpp for Release+Asserts build llvm[2]: Building Release+Asserts Archive Library libLLVMObject.a llvm[2]...