similar to: llvm-objdump: failed to parse debug information

> On Apr 28, 2020, at 9:03 AM, David Blaikie <dblaikie at gmail.com> wrote: > > What does llvm-dwarfdump tell you? > (particularly `--verify`) -- adrian

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

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

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

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

I've made a change to llvm-objdump and feel uncomfortable checking it in without a test case. Where do the "make check" tests for tools like llvm-objdump go? Worse comes to worse, I'll stick it in test/MC/Mips since it is there I need the change for other Mips/MC tests. Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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:

Hello, $ objdump -h # displays info about all below sections.... Sections: Idx Name Size VMA LMA File off Algn While, $ llvm-objdump -h # only displays subset of info... Sections: Idx Name Size Address Type Using '--show-lma' could get VMA and LMA details. Can you suggest options to print 'File off' and

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

On Mon, Aug 27, 2012 at 11:07 AM, Carter, Jack <jcarter at mips.com> wrote: > I've made a change to llvm-objdump and feel uncomfortable checking > it in without a test case. Where do the "make check" tests for tools like > llvm-objdump go? > > Worse comes to worse, I'll stick it in test/MC/Mips since it is there I need > the change for other Mips/MC tests.

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? > > [

Hi all, I try to compile my package kml and I get the message Warning in read_symbols_from_dll(so,rarch): this requires 'objdump.exe' to be on the PATH I check 'Writing R Extensions' but I did not find any reference to this error. Does someone know how to fix that? Thank you very much for your help. Christophe

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()

On Thu, Oct 17, 2013 at 10:55 AM, Stephen Checkoway <s at pahtak.org> wrote: > 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 >

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

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.

Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's

I would like to improve llvm-objdump. However, many unit tests depend precisely on the current output, making the picture a little tricky. My experience is limited to ELF format objects, so experts in other formats please sanity check. Suggested changes: 1) Symbolize conditional branch targets. Currently, llvm-objdump prints branch targets numerically regardless of -symbolize. 2) Make

Thanks James it seems worked for me :) I am facing some issues in login into bugs.llvm.org, I will file once I get access. Pls feel free if you have login :) Thank you again. From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, July 8, 2020 1:58 PM To: Oza, Hiral <Hiral.Oza at netapp.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] llvm-objdump print