search for: mcobjectwriter

.... > > +  // 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) &g...

.../MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h @@ -669,7 +669,9 @@ public: - void Finish(); + /// \arg Writer is used for custom object writer (as the MCJIT does), + /// if not specified it is automatically created from backend Nit: End complete sentences end with a period. + void Finish(MCObjectWriter *Writer = 0); diff --git include/llvm/Target/TargetMachine.h include/llvm/Target/TargetMachine.h index 227499b..a115877 100644 --- include/llvm/Target/TargetMachine.h +++ include/llvm/Target/TargetMachine.h @@ -244,6 +244,15 @@ public: bool = true) {...

...MCAssembler.h > @@ -669,7 +669,9 @@ public: > -  void Finish(); > +  /// \arg Writer is used for custom object writer (as the MCJIT does), > +  /// if not specified it is automatically created from backend > > Nit: End complete sentences end with a period. > > +  void Finish(MCObjectWriter *Writer = 0); > diff --git include/llvm/Target/TargetMachine.h > include/llvm/Target/TargetMachine.h > index 227499b..a115877 100644 > --- include/llvm/Target/TargetMachine.h > +++ include/llvm/Target/TargetMachine.h > @@ -244,6 +244,15 @@ public: >                            ...

...liant. Apply it with "patch -p0". + // 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(&q...

...email sooner. > >> In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? >> >> I assume, a MCJITStreamer is needed. >> And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? >> >> What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? > > I'm not sure the best path for...

...Triple).getEnvironmentName().equals("JIT")) { AsmStreamer.reset(createJITStreamer(*Context, *TAB, Out, MCE)); } else { AsmStreamer.reset(createMachOStreamer(*Context, *TAB, Out, MCE)); } What do you think ? Do you consider this to be acceptable ? Or just horrible ? - MCObjectWriter::Write8 and MCObjectWriter::WriteBytes are designed to write in a raw_ostream instance, to adapt them to the JIT, I see 2 possibilities : - Add a virtual keyword on Write8/WriteBytes and re-implement them in JITObjectWriter ? This is my current solution but I fear it's not so good for the per...

...is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > proven somewhat problematic, mostly due to my lack of understanding. > I guess MCSectionXXX was meant to provide communication between them. > Should the same be true of MCSymbol, and their data counterparts? I'm enclosing my patch for reforming MCSectionCOFF to match the implem...

...Chris, Thanks for taking time to communicate on this. In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? I assume, a MCJITStreamer is needed. And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? What was on your mind on this subject ? Anyone has already beg...

...cpp >> index 2cf65c1..02ac2be 100644 >> --- a/lib/Target/X86/X86AsmBackend.cpp >> +++ b/lib/Target/X86/X86AsmBackend.cpp >> @@ -14,6 +14,7 @@ >>  #include "llvm/MC/MCAssembler.h" >>  #include "llvm/MC/MCExpr.h" >>  #include "llvm/MC/MCObjectWriter.h" >> +#include "llvm/MC/MCSectionCOFF.h" >>  #include "llvm/MC/MCSectionELF.h" >>  #include "llvm/MC/MCSectionMachO.h" >>  #include "llvm/MC/MachObjectWriter.h" >> @@ -212,6 +213,24 @@ public: >>      : ELFX86AsmBacke...

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

Hi all, I want to create a command line arg that affects if MCObjectWriter (Particularly ELFObjectWriter) includes some special data or not. I have created args before and have not had a problem creating passes based on their existence. However, at the level that MCObjectWriter exists, I can't figure out how to pipe the information to it, or how to get ahold of the...

...MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication between them. > > Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch for reforming MCSectio...

...ed responding to this email sooner. > In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? > > I assume, a MCJITStreamer is needed. > And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? > > What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? I'm not sure the best path forward on this, Dani...

...MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication between them. > > Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch for reforming MCSection...

...> The important point here is that the COFF MCSection needs to have the right > level of semantic information. In fact, MCSection is the place that I'd > start for COFF bringup. > > OK, I see that now. The current isolation between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly due to my lack of understanding. I guess MCSectionXXX was meant to provide communication between them. Should the same be true of MCSymbol, and their data counterparts? > > instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, > i...

...>> > have the right level of semantic information. In fact, >> > MCSection is the place that I'd start for COFF bringup. >> > >> > OK, I see that now. The current isolation >> > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has >> > proven somewhat problematic, mostly due to my lack of understanding. >> > I guess MCSectionXXX was meant to provide communication between them. >> > Should the same be true of MCSymbol, and their data counterparts? >> >> I'm enclosing my patch for...

...tion_map; Unused typedefs? 5. For the following bit (and a few others in the same function): + for (i = Sections.begin(), j = Asm.begin(); + (i != Sections.end()) && (j != Asm.end()); + i++, j++) { http://llvm.org//docs/CodingStandards.html#ll_end 6. +namespace llvm { MCObjectWriter * createWinCOFFObjectWriter (raw_ostream & OS); } If you need a function to be visible across files, use a header; shortcuts like this make the code more difficult to read. -Eli

...e same function): > + for (i = Sections.begin(), j = Asm.begin(); > + (i != Sections.end()) && (j != Asm.end()); > + i++, j++) { > > http://llvm.org//docs/CodingStandards.html#ll_end > > I will recode those statements. > 6. > +namespace llvm { MCObjectWriter * createWinCOFFObjectWriter > (raw_ostream & OS); } > > If you need a function to be visible across files, use a header; > shortcuts like this make the code more difficult to read. > > On this one, it didn't seem appropriate to include WinCOFFObjectWriters header into X86A...

...ils 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" > #include "llvm/Support/ELF.h" > +#include <vector> > > namespace llvm { > class MCELFObjectTargetWriter { > @@ -27,6 +28,33 @@ protected: > uint16_t EMachine_, bool Ha...

...c1..02ac2be 100644 >>> --- a/lib/Target/X86/X86AsmBackend.cpp >>> +++ b/lib/Target/X86/X86AsmBackend.cpp >>> @@ -14,6 +14,7 @@ >>>  #include "llvm/MC/MCAssembler.h" >>>  #include "llvm/MC/MCExpr.h" >>>  #include "llvm/MC/MCObjectWriter.h" >>> +#include "llvm/MC/MCSectionCOFF.h" >>>  #include "llvm/MC/MCSectionELF.h" >>>  #include "llvm/MC/MCSectionMachO.h" >>>  #include "llvm/MC/MachObjectWriter.h" >>> @@ -212,6 +213,24 @@ public: >>&g...