search for: objdumper

Displaying 20 results from an estimated 927 matches for "objdumper".

2014 Dec 02
5
[LLVMdev] Making llvm-objdump more like GNU objdump
Hey folks, This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style for ELF). Kevin’s
2014 Dec 02
2
[LLVMdev] Making llvm-objdump more like GNU objdump
Hello LLVM, Previously, some folks wanted llvm-objdump to behave more like GNU objdump. This could encompass both command line options and output format. Such a change helps developers already familiar with GNU tools and allows re-use of Perl scripts or other automation expecting to see GNU style dumps. Is moving llvm-objdump toward GNU objdump the general preference? And what about otools
2020 Apr 28
5
llvm-objdump: failed to parse debug information
Hi, In a 32-bit ARM build, I am seeing the following warning (edited for simplicity, I can provide full logs if necessary): > llvm-objdump -l -d -x file.elf > llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf All object files and static libraries seem to have debug info (i.e., llvm-objdump does not complain when run on each file individually and
2014 Dec 02
2
[LLVMdev] Making llvm-objdump more like GNU objdump
At least for now, I don’t expect it to become all that unwieldy. Any behavioral differences should be easily separable into different classes and source files. If as things progress it becomes obvious that there’s really not much of anything in common other than the general nature of the tools, it’s easy to split them apart. -Jim > On Dec 1, 2014, at 5:20 PM, Steve King <steve at
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2016 May 24
1
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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? >>> >>>
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2014 Dec 03
3
[LLVMdev] Making llvm-objdump more like GNU objdump
OK. Let's try a specific example: At least for ELF files, GNU objdump prints operand values in hex. AFAIK, hex is not just the default, but the only choice. On the other hand, llvm-objdump prints operand values in decimal and ignores the --print-imm-hex option for ELF. How about a patch to print operands in hex for ELF? Good place to start? On Mon, Dec 1, 2014 at 5:49 PM, Kevin Enderby
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2016 Mar 24
0
[llvm] r263971 - [llvm-objdump] Printing relocations in executable and shared object files. This partially reverts r215844 by removing test objdump-reloc-shared.test which stated GNU objdump doesn't print relocations, it does.
While trying 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
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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>,
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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 all the uses of those symbols appear bracketed in > HAVE_LIBXAR, so I don't know what went wrong for you. The trigger for this build failure is the usage of -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON. If I drop that
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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
2020 Jun 16
2
How to fixup source paths during objdump disassembly?
Hi folks, As part of our build, the Tock project uses remap-path-prefix [1] to create a reproducible build. This means that the paths inside of built artifacts are not full source paths. When we later attempt to produce a listings file, the source mapping fails. The result is many copies of this recently merged warning [2]: llvm-objdump: warning:
2013 Oct 17
2
[LLVMdev] llvm-objdump disassembling jmp
In creating a test case for a bug fix in llvm-objdump, I noticed that it differs in its output of pc-relative immediates from objdump: [secdev:/tmp] s$ cat a.s main: jmp .LBL0 .LBL0: ret [secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o [secdev:/tmp] s$ objdump -d a.o |tail -n 2 0: eb 00 jmp 2 <main+0x2> 2: c3 retq
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
Kevin Enderby added those symbol uses in r270491. It has a cmake feature test, and all the uses of those symbols appear bracketed in HAVE_LIBXAR, so I don't know what went wrong for you. On Tue, May 24, 2016 at 8:07 AM, Jack Howarth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in > current trunk? > > [
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
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 all the uses of those symbols appear bracketed in >> HAVE_LIBXAR, so I don't know what went wrong for you.
2012 Jan 23
3
[LLVMdev] ELFObjectFile changes, llvm-objdump showing 'wrong' values?
Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset()