search for: createobjectwrit

...ot;. + // Make sure the code model is set. + setCodeModelForStatic(); For the JIT, this should be setCodeModelForJIT; it makes a difference on, for example, x86-64. I'd also suggest changing the name of the method appropriately. - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + Writer = getBackend().createObjectWriter(OS); + if (!Writer) + report_fatal_error("unable to create object writer!"...

...del is set. > +  setCodeModelForStatic(); > > For the JIT, this should be setCodeModelForJIT; it makes a difference > on, for example, x86-64.  I'd also suggest changing the name of the > method appropriately. > > -  llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); > -  if (!Writer) > -    report_fatal_error("unable to create object writer!"); > +  MCObjectWriter *Writer = Writer_; > +  if (Writer == 0) { > +      Writer = getBackend().createObjectWriter(OS); > +      if (!Writer) > +          report_fatal_error("un...

...delForJIT(); + + return false; // success! +} + -void MCAssembler::Finish() { +void MCAssembler::Finish(MCObjectWriter *Writer_) { Why two variables Writer_ and Writer? I don't know of any rules against modifying parameters. ... - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + + llvm::OwningPtr<MCObjectWriter> OwnWriter(0); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + //no custom Writer_ : create the default one life-managed by OwningPtr + OwnWrite...

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 some code refactoring so that a backend can create it's own ELFObjectWriter class and...

> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.

...+ > > -void MCAssembler::Finish() { > +void MCAssembler::Finish(MCObjectWriter *Writer_) { > > Why two variables Writer_ and Writer?  I don't know of any rules against > modifying parameters. > > ... > > -  llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); > -  if (!Writer) > -    report_fatal_error("unable to create object writer!"); > + > +  llvm::OwningPtr<MCObjectWriter> OwnWriter(0); > +  MCObjectWriter *Writer = Writer_; > +  if (Writer == 0) { > +    //no custom Writer_ : create the default one life...

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

......, MCTargetOptions) -> (*MCAsmBackendCtorFn)(..., MCTargetOptions) -> <MCAsmBackend subclass constructor wanting options>(..., MCTargetOptions) adds MCTargetOptions to the MCAsmBackend subclass state or the bits needed <MCAsmBackend subclass wanting options>::createObjectWriter(...) -> create<foo>ObjectWriter(..., added information) -> <foo>ObjectWriter::<foo>ObjectWriter(..., added information) sets added state based on constructor args, in my case the ABI, IsILP32 <foo>ObjectWriter::GetRelocType(...) use state to guide whic...

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

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 >

..., ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

..., ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

..., ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

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

I am implementing a defined, but currently 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

...the same problem as FDECFEEncoding. · createMCInstrInfo() · createMCInstPrinter() · createMCCodeEmitter() · createMCAsmBackend() · If emitting assembly, createMCAsmStreamer() · if emitting object, createMCObjectStreamer() o This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

..., ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

...the same problem as FDECFEEncoding. • createMCInstrInfo() • createMCInstPrinter() • createMCCodeEmitter() • createMCAsmBackend() • If emitting assembly, createMCAsmStreamer() • if emitting object, createMCObjectStreamer() o This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32...

...quot;Invalid fixup offset!"); + + // For each byte of the fragment that the fixup touches, mask in the bits + // from the fixup value. + for (unsigned i = 0; i != NumBytes; ++i) { + Data[Offset + i] |= uint8_t((Value >> (i * 8)) & 0xff); + } + } + + MCObjectWriter *createObjectWriter(raw_ostream &OS) const { + return createAArch64MachOObjectWriter(OS, MachO::CPU_TYPE_ARM64, + MachO::CPU_SUBTYPE_ARM64_ALL); + } +}; + class ELFAArch64AsmBackend : public AArch64AsmBackend { public: uint8_t OSABI; @@ -581,5 +721,7 @@ MCAsmBack...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because