search for: machoobjectfile

Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in current trunk? [ 95%] Linking CXX executable ../../bin/llvm-objdump 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 i...

...a bootstrap failure on x86_64-apple-darwin15 in >> current trunk? >> >> [ 95%] Linking CXX executable ../../bin/llvm-objdump >> 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::obje...

...t; Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in > current trunk? > > [ 95%] Linking CXX executable ../../bin/llvm-objdump > 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*...

...>>>> current trunk? >>>> >>>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>>> 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: >>>...

...x86_64-apple-darwin15 in >>> current trunk? >>> >>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>> 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: >>> DumpBitco...

...les/LLVMObject.dir/Binary.cpp.o > CMakeFiles/LLVMObject.dir/COFFObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/ELF.cpp.o > CMakeFiles/LLVMObject.dir/ELFObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/Error.cpp.o > CMakeFiles/LLVMObject.dir/IRObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/MachOObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/MachOUniversal.cpp.o > CMakeFiles/LLVMObject.dir/ModuleSummaryIndexObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/Object.cpp.o > CMakeFiles/LLVMObject.dir/ObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/RecordStreamer.cpp.o > CMakeFiles/LLVMObject.dir/...

...gt;>>>> >>>>>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>>>>> 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"...

...urrent trunk? >>>>> >>>>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>>>> 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 fro...

...t;>>>>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>>>>>>> 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 >>>>>>>&...

...ir/ArchiveWriter.cpp.o CMakeFiles/LLVMObject.dir/Binary.cpp.o CMakeFiles/LLVMObject.dir/COFFObjectFile.cpp.o CMakeFiles/LLVMObject.dir/ELF.cpp.o CMakeFiles/LLVMObject.dir/ELFObjectFile.cpp.o CMakeFiles/LLVMObject.dir/Error.cpp.o CMakeFiles/LLVMObject.dir/IRObjectFile.cpp.o CMakeFiles/LLVMObject.dir/MachOObjectFile.cpp.o CMakeFiles/LLVMObject.dir/MachOUniversal.cpp.o CMakeFiles/LLVMObject.dir/ModuleSummaryIndexObjectFile.cpp.o CMakeFiles/LLVMObject.dir/Object.cpp.o CMakeFiles/LLVMObject.dir/ObjectFile.cpp.o CMakeFiles/LLVMObject.dir/RecordStreamer.cpp.o CMakeFiles/LLVMObject.dir/SymbolicFile.cpp.o CMakeFiles/...

...> >>>>>>> [ 95%] Linking CXX executable ../../bin/llvm-objdump >>>>>>> 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_f...

...self-explanatory), but not at documenting classes. I'd encourage anyone who has added a class to LLVM to revisit it and see if they can improve the documentation. Another example is object::ObjectFile. You can cast<> or dyn_cast<> these down to object::COFFObjectFiles or object::MachOObjectFiles easily, but object::ELFObjectFile is a template class and there's no documentation of what the template parameter should be, of it if's possible to infer it from the object::ObjectFile somehow. David Who has spent the last week writing a tool that uses the MC layer and found the lack of...

On 25 September 2013 22:13, Preston Briggs <preston.briggs at gmail.com> wrote: > A lot of my difficulty in reading other examples is that it's not clear > what matters and what doesn't. It's what I hope to get by sitting next to > someone and asking questions. Some of this could be addressed in a guide. > I'd start with a chapter on planning. > Another

...     object::COFFObjectFile &In, Buffer &Out);   Error executeObjcopyOnBinary(const CopyConfig &Config,                              object::ELFObjectFileBase &In, Buffer &Out);   Error executeObjcopyOnBinary(const CopyConfig &Config,                              object::MachOObjectFile &In, Buffer &Out);   Error executeObjcopyOnBinary(const CopyConfig &Config,                              object::WasmObjectFile &In, Buffer &Out); 6. Address ranges and single addresses pointing to removed code should be marked    with tombstone value in the input file:  ...

...elocationRef at the moment, this is going to have to be getAddress for MachO and COFF. COFFObjectFile::getRelocationOffset returns R->VirtualAddress, so inside here I’m going to have to find the section it belongs to, add it to the result so it can later be subtracted off by llvm-objdump MachOObjectFile::getRelocationOffset also returns getAnyRelocationAddress so I’ll have to also find its containing section and add this in just so llvm-objdump can later subtract it. Can you detail why this is a better plan? From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Thursday, Mar...

...amp;Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::ELFObjectFileBase &In, > Buffer &Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::MachOObjectFile &In, Buffer > &Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::WasmObjectFile &In, Buffer > &Out); > > 6. Address ranges and single addresses pointing to removed code > should...

...amp;Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::ELFObjectFileBase &In, > Buffer &Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::MachOObjectFile &In, Buffer > &Out); >    Error executeObjcopyOnBinary(const CopyConfig &Config, >                               object::WasmObjectFile &In, Buffer > &Out); > > 6. Address ranges and single addresses pointing to removed code > should...

...uffer &Out); >>    Error executeObjcopyOnBinary(const CopyConfig &Config, >> object::ELFObjectFileBase &In, Buffer &Out); >>    Error executeObjcopyOnBinary(const CopyConfig &Config, >>                               object::MachOObjectFile &In, >> Buffer &Out); >>    Error executeObjcopyOnBinary(const CopyConfig &Config, >>                               object::WasmObjectFile &In, >> Buffer &Out); >> >> 6. Address ranges and single address...

On Tue, Nov 6, 2012 at 2:19 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > Binutils and LLVM > > As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. > > As a start, I'd like to summarize the current status, and

...fer &Out); >>>    Error executeObjcopyOnBinary(const CopyConfig &Config, >>> object::ELFObjectFileBase &In, Buffer &Out); >>>    Error executeObjcopyOnBinary(const CopyConfig &Config, >>> object::MachOObjectFile &In, Buffer &Out); >>>    Error executeObjcopyOnBinary(const CopyConfig &Config, >>> object::WasmObjectFile &In, Buffer &Out); >>> >>> 6. Address ranges and single addresses pointing to >>>...