search for: machodump

...Undefined symbols for architecture x86_64: "_xar_serialize", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in MachODump.cpp.o "_xar_file_first", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in MachODump.cpp.o "_xar_iter_n...

...t;> "_xar_serialize", referenced from: >> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >> unsigned int, bool, bool, bool, std::__1::basic_string<char, >> std::__1::char_traits<char>, std::__1::allocator<char> >) in >> MachODump.cpp.o >> "_xar_file_first", referenced from: >> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >> unsigned int, bool, bool, bool, std::__1::basic_string<char, >> std::__1::char_traits<char>, std::__1::allocator<char> >) in...

...hitecture x86_64: > "_xar_serialize", referenced from: > DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, > unsigned int, bool, bool, bool, std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> >) in > MachODump.cpp.o > "_xar_file_first", referenced from: > DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, > unsigned int, bool, bool, bool, std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> >) in > MachODump....

...ot;, referenced from: >>>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>>> std::__1::char_traits<char>, std::__1::allocator<char> >) in >>>> MachODump.cpp.o >>>> "_xar_file_first", referenced from: >>>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>>> std::__1::char_traits<char>, std::__1...

...xar_serialize", referenced from: >>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>> std::__1::char_traits<char>, std::__1::allocator<char> >) in >>> MachODump.cpp.o >>> "_xar_file_first", referenced from: >>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>> std::__1::char_traits<char>, std::__1::allocator<c...

...elete-non-virtual-dtor -Werror=date-time -std=c++11 -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar eliminates the bootstrap failure. > > Kev > >> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: >> >> On Tue, May 24, 2016 a...

...elete-non-virtual-dtor -Werror=date-time -std=c++11 -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump ../../lib/libLLVMX86AsmPrinter.dylib ../../lib/libLLVMPowerPCAsmPrinter.dylib ../../lib/libLLVMARMAsmPrinter.dylib ../../lib/libLLVMX86Desc.dylib ../../lib/libLLVMPowerPCDesc.dylib ../../lib/libLLVMARMDesc.dylib ../../lib/libLLVMX86Disassembler.dylib ../../lib/libL...

...from: >>>>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>>>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>>>> std::__1::char_traits<char>, std::__1::allocator<char> >) in >>>>> MachODump.cpp.o >>>>> "_xar_file_first", referenced from: >>>>> DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, >>>>> unsigned int, bool, bool, bool, std::__1::basic_string<char, >>>>> std::__1::char_traits<char...

...=c++11 -O3 >> -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib >> -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o >> CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o >> CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o >> CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump >> ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar >> >> eliminates the bootstrap failure. >> >>> >>> Kev >>> >>>> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists...

...gt; -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib >>> -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o >>> CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o >>> CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o >>> CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump >>> ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar >>> >>> eliminates the bootstrap failure. >>> >>>> >>>> Kev >>>> >>>>> On May 24, 2016, at 10:28 AM, Jack H...

...error=date-time -std=c++11 -O3 > -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib > -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o > CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o > CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o > CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump > ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar > > eliminates the bootstrap failure. > >> >> Kev >> >>> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: &gt...

...rn ec.value(); } Binary &Binary = *BinaryOrErr.get().getBinary(); object::ObjectFile *objfile; objfile = dyn_cast<ObjectFile>(&Binary); for (const SymbolRef &Symbol : objfile->symbols()) { uint64_t size; Symbol.getAddress(size); } #### During my previous search, I check machODump.cpp in order to see of the list all the function. They never use the getSize() but they use the address (getAddress()) of the next function. Does anyone have ever heard of a bug with this function or did I do something wrong? Greeting, Johan Wehrli

Hi Stanislav Thanks for checking on this. If you want a quick hack, you can try to read the code in tools/llvm-objdump/MachODump.cpp. There are some c code in there to parse metadata. My code is something I put up for my own purpose for debugging/parsing objc metadata. The interface is a bit rough to use but the biggest problem is testing. I have my own binary living out of tree to test the parser but it doesn't make se...

...ning multiple disassemblers down into the core disassembler logic and using subtarget to select between them. Like the ARMAsmParser and I think the ARMInstPrinter work. But that seems very complicated for a single target that has two disassemblers. The implementation of llvm-objdump does have a MachODump.cpp for use with the -m option that I could do the a similar hack otool(1) like hack and special case 32-bit ARM cpus. And at least it contains the ugliness. But this does not really help the non -m case and I suspect ELF objects may face a similar problem. The other more radical change I was th...

Hi Kevin I am just pointing out that is a good place to look at how metadata is parsed and it supports parsing metadata from pre-linked object file which is important to JIT. My code pretty much replicate most of the functions in MachODump in C++ and hope it can much more reusable than the c parser. The biggest missing part is the resilience to bad metadata due to the fact we currently don't have good way to recover from error but I know Chris B is working on something like that. I will definitely ask more feedback from you when...

On Thu, Aug 7, 2014 at 7:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> The implementation of llvm-objdump does have a MachODump.cpp for use with the -m option that I could do the a similar hack otool(1) like hack and special case 32-bit ARM cpus. And at least it contains the ugliness. But this does not really help the non -m case and I suspect ELF objects may face a similar problem. > > My gut feeling would be to do...

> So no JIT for i386? I didn't realise i386 still used ObjC 1 - all my experiments were on arm64. i386 support for ObjC would be nice to have, but it's not a blocker for adding ObjC 2 support. - Lang. On Thu, Oct 20, 2016 at 11:57 AM, Steven Wu <stevenwu at apple.com> wrote: > > > > On Oct 19, 2016, at 11:28 AM, Stanislav Pankevich <s.pankevich at

...n terminated. [3188/4317] Building CXX object tools/llvm-cfi-verify/lib/CMakeFiles/LLVMCFIVerify.dir/GraphBuilder.cpp.o [3189/4317] Building CXX object tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o [3190/4317] Building CXX object tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/MachODump.cpp.o ninja: build stopped: subcommand failed. loki build 189 loki build 189 find /export2/src/llvm-6.0.0/llvm-6.0.0rc2.src -name Version.h /export2/src/llvm-6.0.0/llvm-6.0.0rc2.src/tools/cfe-6.0.0rc2.src/include/clang/Basic/Version.h /export2/src/llvm-6.0.0/llvm-6.0.0rc2.src/tools/lld-6.0.0rc2.src...

...diff' llvm[2]: Compiling ELFDump.cpp for Release+Asserts 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 (wi...