search for: coffdumper

tools/llvm-objdump/COFFDump.cpp has two loops that advance the loop iterator using "I = ++I" instead of the usual "++I". For example: import_directory_iterator I = Obj->import_directory_begin(); import_directory_iterator E = Obj->import_directory_end(); if (I == E) return; outs() << "The Import Tables:\n"; for (; I != E; I = ++I) {

Oops, meant to send this to the mailing list instead of to Reid privately. (Why cc the mailing list instead of just sending to the mailing list?) In article <CACs=tyJ6zaHeiS0eNhBkdcZE--JY4k7yH9_P1yFbGqod6uymMw at mail.gmail.com>, Reid Kleckner <rnk at google.com> writes: > Looks like a bug. This can probably be simplified with C++11. > > On Fri, Apr 4, 2014 at 10:39

On Mon, Apr 7, 2014 at 12:09 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Apr 07, 2014 at 08:38:58AM -0600, Richard wrote: > > Oops, meant to send this to the mailing list instead of to Reid > > privately. (Why cc the mailing list instead of just sending to the > > mailing list?) > > > > In article <CACs= >

...FF.h so that it doesn't clash? I know windows.h is quite invasive, so maybe it's better not try to collide with any of its weird define. If that makes sense I'm fine with doing the patch. If yes, feel free to propose an alternative naming prefix or scheme. Note that if tools depend on COFFDumper::printFileHeaders output, it might still need to print as it was before -- so the easiest choice might be to maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't matter). Is it important? Thanks, Virgile -------------- next part -------------- An HTML attachment was scrubb...

...? > I know windows.h is quite invasive, so maybe it's better not try to > collide with any of its weird define. > > If that makes sense I'm fine with doing the patch. > If yes, feel free to propose an alternative naming prefix or scheme. > > Note that if tools depend on COFFDumper::printFileHeaders output, it might > still need to print as it was before -- so the easiest choice might be to > maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't > matter). Is it important? > > Thanks, > Virgile > > ______________________________...

On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: > Hi Jack, > > Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: > > #ifdef HAVE_LIBXAR > extern "C" { > #include <xar/xar.h> > } > #endif > > I think we

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

Jack, What version of CMake are you using? -Chris > On May 24, 2016, at 11:00 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: >> Hi Jack, >> >> Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not

...is quite invasive, so maybe it's better not try to >> collide with any of its weird define. >> >> If that makes sense I'm fine with doing the patch. >> If yes, feel free to propose an alternative naming prefix or scheme. >> >> Note that if tools depend on COFFDumper::printFileHeaders output, it >> might still need to print as it was before -- so the easiest choice might >> be to maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't >> matter). Is it important? >> >> Thanks, >> Virgile >> >&gt...

Hi Jack, Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: #ifdef HAVE_LIBXAR extern "C" { #include <xar/xar.h> } #endif I think we may need some help from Chris to track this down. I’ll bug him in a bit to see if he can help us on this. Kev > On May 24, 2016, at

On Tue, May 24, 2016 at 1:24 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 1:22 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 12:08 PM, Reid Kleckner <rnk at google.com> wrote: >>> Kevin Enderby added those symbol uses in r270491. It has a cmake >>> feature test, and

...s build llvm[2]: Compiling ARMWinEHPrinter.cpp for Release+Asserts build make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/tools/llvm-rtdyld' llvm[2]: Compiling llvm-rtdyld.cpp for Release+Asserts build llvm[2]: Compiling MachODump.cpp for Release+Asserts build llvm[2]: Compiling COFFDumper.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable llvm-rtdyld (without symbols) llvm[2]: Compiling ELFDumper.cpp for Release+Asserts build llvm[2]: ======= Finished Linking Release+Asserts Executable llvm-rtdyld (without symbols) make[2]: Leaving directory '/home/NIKHILR...