similar to: [LLVMdev] llvm-objdump related patch

On Tue, Oct 11, 2011 at 12:15 AM, Neo <smtian at ingenic.cn> wrote: > Hi, >    I am new to llvm, not familiar with c++, after some use with > llvm-objdump, and finding the broken output, I try to debug and fix the code > so it can become usable. Please help review the patch, so that they can be > merged. >    And there's still two major problem I have found about arm

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

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > 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 > @@ -747,12 +747,28 @@ error_code

Neo, On Oct 11, 2011, at 12:15 AM, Neo wrote: > 1. arm instruction decoder cannot recognise bx series instructions. Can you provide a testcase for an instruction it fails to disassemble? --Owen

2012/1/23 Bendersky, Eli <eli.bendersky at intel.com>: > Hi, > > I would like to examine the implications you mention in more detail. > Thank you! > (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

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

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

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

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

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

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

On Thu, Aug 7, 2014 at 7:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> The implementation of llvm-objdump does have a MachODump.cpp for use with the -m option that I could do the a similar hack otool(1) like hack and special case 32-bit ARM cpus. And at least it contains the ugliness. But this does not really help the non -m case and I suspect ELF objects may face

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

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

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:

Hi Kev, I'm glad to hear llvm-objdump is getting attention. I'm unclear on how much output specialization one could (or should) do for ELF vs. Mach-O. If you're game, let's compare an example: $ cat labeltest.s .text foo: nop bar: bum: nop jmp bar jmp bum jmp baz nop baz: nop Assembling for x86 and llvm-objdump'ing, i get $ llvm-mc

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 >

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

I am using llvm-project compiling risc-v programs. llvm-project version:dd8a2013dc1804be1b7d9cffacad2e984300bd22 Instructons to build LLVM+clang: ``` cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/home/llvm/workspace/llvm/llvm-project/llvm_install -DCMAKE_BUILD_TYPE="Release" -DDEFAULT_SYSROOT="/home/llvm/workspace/riscv/riscv-tc-20200220/bin/riscv32-unknown-elf"

Hi, I'm considering to use MC disassembler for ARM target in a binary translation project. However after trying some ARM binary and I find that there are a lot of instructions that the disassembler fails to to decoding. Could anyone give me some information about the maturity of ARM disassembler? Thanks! David -------------- next part -------------- An HTML attachment was scrubbed... URL: