similar to: [RFC] Support disassembly of ARM and thumb mixed in single ELF file

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

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 a section o

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool that regular user

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

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 Everyone, When I used llvm-objdump to disassemble an ELF armv7 or thumb I have this error message: llvm-objdump: warning: invalid instruction encoding This message appears directly into the output and the output is mostly wrong (the invalid instruction create a shift in the addresses) : 1a6d: ff 2f e1 08 stmeq r1!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, sp} ^ 1a71: 30

The standard objdump does not recognised the format. It works if I used an arm-linux-androideabi-objdump from the Android ndk but I am using the clang API to read binary inside my soft. This is why I was only working with llvm-objdump. > On 19 Jun 2016, at 15:03, Bruce Hoult <bruce at hoult.org> wrote: > > What happens if you use the standard bunutils objdump e.g. from macports

I built llvm + clang from source, a github clone from today: clang version 11.0.0 (https://github.com/llvm/llvm-project.git 91aa67bf290bc7f877b1b90128284863bc31aa43) I compiled a small program: #include <stdint.h> int main() { uint8_t a = 2; uint8_t b = 5; uint8_t c = a * b; } $ clang -c -target riscv32 -march=rv32imc -g main.c Works fine. The dumped assembly seems to not know

I'm attempting to detect encoding bugs by comparing disassembly when using GCC's 'as' versus LLVM's integrated assembler. Generally this has gone very well, but one thing that adds a lot of noise is that .word marked as a R_ARM_ABS32 is disassembled as an instruction and not data. Please see the attached 'dump.diff' which was generated by diffing the "objdump -d

Hi Greg, > Is this a bug? If so, how can I fix it? It's somewhere between a bug and a quality-of-implementation issue. ARM often uses literal pools in the middle of code when it needs to materialize a large constant (or variable address more likely for R_ARM_ABS32). This results in a sequence roughly like: ldr r0, special_lit_sym [...] b past_literals special_lit_sym:

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 Nowadays I am using LLVM to do ARM binary analysis. I was wondering is llvm available to provide some debugging information on the mode of ARM. For example, llvm-dwarfdump could dump some instructions information for debugging. Is it able to know the mode for each instruction? Or we may write some llvm pass to help us to know the instruction mode? Any suggestions are welcomed. Many Thanks

Hi Evan, Thanks for the information! I've try to use llvm-objdump to disassemble some ARM binary, such as busybox in android. ./llvm-objdump -arch=arm -d busybox There are many instructions cannot decode, :./llvm-objdump: warning: invalid instruction encoding Did I use llvm-objdump in a correct way? I think that one possible reason is that llvm-objdump encounter pc relative data.

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 David, > I've try to use llvm-objdump to disassemble some ARM binary, such as busybox > in android. > > ./llvm-objdump -arch=arm -d busybox It's probably assuming the wrong architecture revision. I don't have an android busybox handy, but I see similar on binaries compiled for ARMv7. The trick is to use: llvm-objdump -triple=armv7 -d whatever (ARMv7 covers virtually

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:

On Jun 5, 2012, at 7:44 PM, Fan Dawei <fandawei.s at gmail.com> wrote: > 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

Hi all. I'm investigating an issue with incorrect lldb's disassembly output. I have two bytes in question: 4e5f lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics: ldr r6, #380, However the value for ldr is "an 8-bit value that is multiplied by 4 and added to the value of the PC to form the memory address" (via ARMARM), so that the correct

On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: >> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >