similar to: [LLVMdev] Looking for ideas on how to make llvm-objdump handle both arm and thumb disassembly from the same object file

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

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 Aiden, The 'C' based interface you could use in is llvm/include/llvm-c/Disassembler.h, which in there is: /** * Disassemble a single instruction using the disassembler context specified in * the parameter DC. The bytes of the instruction are specified in the * parameter Bytes, and contains at least BytesSize number of bytes. The * instruction is at the address specified by the

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

Hi, My apologies if this appears to be a very trivial question -- I have tried to solve this on my own and I am stuck. Any assistance that could be provided would be immensely appreciated. What is the absolute bare minimum that I need to do to disassemble an array of, say, ARM machine code bytes? Or an array of Thumb machine code bytes? For example, I might have an array of unsigned chars -- how

Hi Aiden, The easiest thing I can do is to point you to the source of the "llvm-mc" tool, which does exactly what you ask in its "-disassemble" mode. The code is rather small, so it should be easy to work out. tools/llvm-mc Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aidan Steele Sent:

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

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

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

Hi Kev and James, Thanks to both of you for responding. I had looked at the otool release published for 10.7.2 (cctools-800), but it seems that it only snuck in after that and by the cctools-809 release! In any case, both that and llvm-mc should be more than adequate! A follow-up question: is the C interface to LLVM a second-class citizen or should I reasonably be able to expect to do everything

Hi, I have been trying to use LLVM as a disassembler, thus providing a small part of my decompiler that I am working on. It currently decompiles from X86_64 binary.o -> LLVM IR. It works with a small set of test programs so far, so cannot currently handle large binary programs yet. The problem is with the LLVM "getInstruction()" method. It used to have a PC (program counter)

Hi all. I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) { llvm::Target target = from_ruby<llvm::Target>(self); char const

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

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.

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 >

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