search for: datarefimpl

...factory methods return ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error appropriately. (b) is harder. The current approach is to use std::error_code as a return type, and store the result in by-reference argument, for instance: std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); I wanted to follow this approach in a proposed large MachO API change (http://reviews.llvm.org/D10111), but it raised discussion on whether this approach is right. Moving this discussion here. I see the following options: 1. Use the current approach: std::error_code...

...ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); > > I wanted to follow this approach in a proposed large MachO API change > (http://reviews.llvm.org/D10111), but it raised discussion on whether this > approach is right. > Moving this discussion here. I see the following options: > > 1. Use the cur...

...ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); > > I wanted to follow this approach in a proposed large MachO API change > (http://reviews.llvm.org/D10111 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10111&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGg...

...names, wherein it was attempting to parse the leading '/' in an extended symbol name reference as part of the integer offset. - Fixes bugs in COFFObjectFile and ELFObjectFile wherein section and symbol iterators were being returned with uninitialized bytes; the type DataRefImpl is a union between 2 32-bit words (d.a and d.b) and a single intptr_t word (p). Only p was being initialized, so in 32-bit builds the result would be iterators with random upper 32-bit words in their DataRefImpls. This caused random failures when seeking around in object files....

...>>, and we should propagate the error >>> appropriately. >>> >>> (b) is harder. The current approach is to use std::error_code as a >>> return type, and store the result in by-reference argument, for instance: >>> std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); >>> >>> I wanted to follow this approach in a proposed large MachO API change >>> (http://reviews.llvm.org/D10111 >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10111&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPl...

...vm-objdump. > > Songmao > @@ -747,12 +747,28 @@ error_code ELFObjectFile<target_endianness, is64Bits> template<support::endianness target_endianness, bool is64Bits> error_code ELFObjectFile<target_endianness, is64Bits> ::sectionContainsSymbol(DataRefImpl Sec, DataRefImpl Symb, bool &Result) const { - // FIXME: Unimplemented. + Result = false; + const Elf_Sym *sym = getSymbol(Symb); + const Elf_Shdr *sec = reinterpret_cast<const Elf_Sh...

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

...this. I was not sure if my implementation was ok, so I wanted to ask if I've done something wrong first. Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0xB at 0x54F4516: llvm::object::COFFObjectFile::moveSectionNext(llvm::object::DataRefImpl&) const (COFFObjectFile.cpp:267) by 0x55A62FB: llvm::object::ObjectFile::isBerkeleyText(llvm::object::DataRefImpl) const (ObjectFile.cpp:80) by 0x5538CF9: llvm::object::RelocationRef::getType() const (ObjectFile.h:543) by 0x55AE53E: llvm::object::resolveARM(llvm::object::RelocationR...

Hi folks, I am trying to implement the C bindings API for DebugInfo::DWARF::DWARFDie. My goal is to have a C library that reads and parses DWARF debugging format (just like how llvm-dwarfdump does, but maybe more than just dumping debug info) I've started with creating C structure for DebugInfo::DWARF::DWARFContext which contains all DWARF DIEs in the object file. For this I used ```

...KaleidoscopeJIT::findMangledSymbol" to also allow non-exported symbols. I fixed it by changing "COFFObjectFile::getSymbolFlags" in llvm-src/lib/Object/COFFObjectFile.cpp to additionally OR SymbolRef::SF_Exported to Result: > uint32_t COFFObjectFile::getSymbolFlags(DataRefImpl Ref) const { > COFFSymbolRef Symb = getCOFFSymbol(Ref); > uint32_t Result = SymbolRef::SF_None; > > if (Symb.isExternal() || Symb.isWeakExternal()) > Result |= SymbolRef::SF_Global | SymbolRef::SF_Exported; Works and sounds reasonable to me, but maybe you can prove me...