search for: machobjectwrit

This should fix this warning from Visual Studio 2010: 33>..\..\..\llvm-2.8svn-build\lib\MC\MachObjectWriter.cpp(772): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) Index: lib/MC/MachObjectWriter.cpp =================================================================== --- lib/MC/MachObjectWriter.cpp (revision 111120) +++ lib/MC/M...

In llvm/lib/MC/MachObjectWriter.cpp, there's assert(OS.tell() - Start == is64Bit() ? macho::Header64Size : macho::Header32Size); Shouldn't that be assert(OS.tell() - Start == (is64Bit() ? macho::Header64Size : macho::Header32Size)); MSVC emits a warning, and it doesn't seem right to...

...(); baz(); } Please see details shown at http://llvm.org/bugs/show_bug.cgi?id=14636 from comment 26 to 32+. Basically, the index into the indirect table for the symbol stubs section looks suspect (IndirectSymBase). I've shown some stack traces that show where the wrong(?) value came from, MachObjectWriter::BindIndirectSymbols(). Can any mach-o experts comment on this finding? Is there some assumption about the order of symbols or sections seen by BindIndirectSymbols()? Fang -- David Fang http://www.csl.cornell.edu/~fang/

...t;>  #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: >>      : ELFX86AsmBackend(T) {} >>  }; >> >> +class WindowsX86AsmBackend : public X86AsmBackend { >> +public: >> +  WindowsX86AsmBackend(const Target &T) >> +    : X86AsmBackend(T) { >> +    HasAbso...

...ot;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: >>>      : ELFX86AsmBackend(T) {} >>>  }; >>> >>> +class WindowsX86AsmBackend : public X86AsmBackend { >>> +public: >>> +  WindowsX86AsmBackend(const Target &T) >>> +    : X86AsmBa...

.... 2. The ELFObjectWriter base class is declared in llvm/MC/MCObjectWriter.h; it may be better to put this declaration in its own header file. 3. Some of the flags, such as Is64Bit and EMachine, could be virtual methods instead of values passed to the base ELFObjectWriter class. 4. Refactoring of MachObjectWriter and WinCOFFObjectWriter could be done as well. 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...

...quot; >>>>  #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: >>>>      : ELFX86AsmBackend(T) {} >>>>  }; >>>> >>>> +class WindowsX86AsmBackend : public X86AsmBackend { >>>> +public: >>>> +  WindowsX86AsmBackend(const Target &T)...

On 26 July 2010 18:08, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > You probably want to add Cygwin and MinGW32 Triples as well :- > > case Triple::Win32: > > + case Triple::Cygwin: > > + case Triple::MinGW32: > > return new

...'ve been trolling through the integrated assembler lately, and had a real "can't tell the players without a program" 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 m...

On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > You probably want to add Cygwin and MinGW32 Triples as well :- >    case Triple::Win32: > +  case Triple::Cygwin: > +  case Triple::MinGW32: >      return new WindowsX86AsmBackend (T); > Aaron Can someone test this on those platforms? That change would effect quite a few people. -

...;> tryB: subclass ELFObjectWriterImpl instead - I am still working out >> the details on this one - but as of right now, it is just as complex >> as the tryA case. >> The only benefit to this is approach is the superficial similarity >> between the ELFObjectWriter and the MachObjectWriter - in that both >> still trampoline into an *Impl class to do the actual work. >> Unfortunately, it also adds a requirement for registering a NEW >> <ARCH>ELFObjecWriterImpl class (i.e. in addition to the existing >> createELFObjectWriter, and without namespace pollut...

...------------------------------------------------------------===// + +#include "MCTargetDesc/AArch64FixupKinds.h" +#include "MCTargetDesc/AArch64MCTargetDesc.h" +#include "llvm/MC/MCAssembler.h" +#include "llvm/MC/MCELFObjectWriter.h" +#include "llvm/MC/MCMachObjectWriter.h" +#include "llvm/MC/MCAsmLayout.h" +#include "llvm/MC/MCContext.h" +#include "llvm/MC/MCSection.h" +#include "llvm/MC/MCValue.h" +#include "llvm/Support/ErrorHandling.h" + +using namespace llvm; + +namespace { +class AArch64MachOObjectWrite...

...t;>  #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: >>>>>      : ELFX86AsmBackend(T) {} >>>>>  }; >>>>> >>>>> +class WindowsX86AsmBackend : public X86AsmBackend { >>>>> +public: >>>>> +  WindowsX86AsmB...

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

...talling: /usr/local/llvm-2.8/include/llvm/MC/MCSectionMachO.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCStreamer.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCSymbol.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCValue.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MachObjectWriter.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/SectionKind.h -- Installing: /usr/local/llvm-2.8/include/llvm/Metadata.h -- Installing: /usr/local/llvm-2.8/include/llvm/Module.h -- Installing: /usr/local/llvm-2.8/include/llvm/OperandTraits.h -- Installing: /usr/local/llvm-2.8/include/llvm/Op...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

...irectory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/ExecutionEngine/MCJIT' llvm[4]: Compiling X86MachORelocationInfo.cpp for Release+Asserts build llvm[3]: Compiling MCJIT.cpp for Release+Asserts build llvm[2]: Compiling BasicTargetTransformInfo.cpp for Release+Asserts build llvm[4]: Compiling X86MachObjectWriter.cpp for Release+Asserts build llvm[3]: Compiling SampleProfile.cpp for Release+Asserts build llvm[3]: Building Release+Asserts Archive Library libLLVMMCJIT.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/ExecutionEngine/MCJIT' make[3]: Entering directory '/home/NIKHI...