search for: relocationref

It sounds like what you’re asking is, rather that universally calling RelocationRef::getOffset inside llvm-objdump.cpp I should: * Check if Obj “isRelocatableObject” * If it is, call RelocationRef::getOffset() * If it isn’t o Call RelocationRef::getAddress() o Build an ordered map of all sections and their bounds, check if the relocation lands within...

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

...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::RelocationRef, unsigned long, unsigned long) (RelocationResolver.cpp:250) by 0x502802B: llvm::DWARFDataExtractor::getRelocatedValue(unsigned int, unsigned int*, unsigned long*) const (DWARFDataExtractor...

...ng to fix a bug where llvm-objdump isn't printing relocations retained with ld -emit-relocs in shared object or executables, it seems like there isn't a way to split printing dynamic relocations from non-dynamic relocations as with GNU objdump -r and -R. I was thinking of adding a function RelocationRef::isDynamic() and filtering them this way when printing. Since RelocationRef covers ELF/COFF/MachO we would need reasonable behaviors for each platform. Does this seem like a good approach and does anyone have input on how this function should behave on COFF/MachO? -----Original Message----- From...

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

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 ```

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk