search for: disassembler

...sbach 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 maybe you would have some thoughts or suggestions. First a little back ground, the way darwin’s otool(1) does this is that it creates an llvm disassembler for both arm and thumb when disassembling a binary with 32-bit ARM cpu. It uses the C API in <llvm-c/Disassembler.h> and calls LLVMCreateDisasmCPU() twice, once with an arm TripleName and once with a matching thumb TripleName. Then for each 32-bit ARM cpu it will default to one or the other...

On Aug 11, 2011, at 1:32 AM, James Molloy wrote: > Hi, > > I’m looking at the new ARM disassembler, and performing testing to see if there are any obvious bugs I can fix. Overall it looks really nice – I’ve only found one obvious bug that I’m packaging up a patch for now. Glad you're liking it! I haven't really done comprehensive testing yet—it passes all the decoding tests that the pr...

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just go into > gdb and type &quo...

...oliu > Date: Wed Nov 27 19:07:45 2013 > New Revision: 195903 > > URL: http://llvm.org/viewvc/llvm-project?rev=195903&view=rev > Log: > AArch64: Fix a bug about disassembling post-index load single element to 4 vectors > > Modified: > llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp > llvm/trunk/test/MC/Disassembler/AArch64/neon-instructions.txt > > Modified: llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp?rev...

Hi, With the new llvm-mc code for disassembling, what is the recommended way to disassemble the final code produced by a JIT compiler backend? (Eg. in the toy.cpp example from the tutorial). I can get the void* for the final code, but I don't know its length - superficially at least it appears I need to know the length to disassemble it as a buffer? Thanks b.

...>> New Revision: 195903 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=195903&view=rev >> Log: >> AArch64: Fix a bug about disassembling post-index load single element to 4 >> vectors >> >> Modified: >> llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp >> llvm/trunk/test/MC/Disassembler/AArch64/neon-instructions.txt >> >> Modified: >> llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/AArch64/Disass...

...;>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=195903&view=rev >>> Log: >>> AArch64: Fix a bug about disassembling post-index load single element to 4 >>> vectors >>> >>> Modified: >>> llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp >>> llvm/trunk/test/MC/Disassembler/AArch64/neon-instructions.txt >>> >>> Modified: >>> llvm/trunk/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp >>> URL: >>> http://llvm.org/viewvc/llvm-project/llvm/trunk/...

...tion *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by the disassembler. You then should be able to either use runJITOnFunction as part of your current JIT compilation process or do the same thing it does by way of registering your own JITEventListener to get access to the required values. > > O.J. > > p.s. let me know if you are successful in getting this...

...From the release announcement it looks like llvm-mc isn't >> ready for >> this purpose yet, was just curious if this kind of task was anywhere >> on its >> roadmap. Thanks... > > We don't have anything like that planned, but do plan to do an > assembler and disassembler. The disassembler (for x86-16/32/64) is > iterating on review comments before it goes in. The assembler is > currently being built out and will initially support macho. > Translating X86-32 to X86-64 sounds tricky but it could probably be > built on some of this infrastructure. Thank...

Hi there! In the x86 disassembler I noticed an if-statement with a duplicated branch. Are these intended to be identical? Best regards, Nicolas Kaiser -- diff -ur llvm-2.8.orig/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c llvm-2.8/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c --- llvm-2.8.orig/lib/Target/X86/Disasse...

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

...tion *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by the disassembler. You then should be able to either use runJITOnFunction as part of your current JIT compilation process or do the same thing it does by way of registering your own JITEventListener to get access to the required values. O.J. p.s. let me know if you are successful in getting this working, I hope yo...

...quot;disas <pointer-to-JITed-code>". More detail here: http://llvm.org/docs/DebuggingJITedCode.html If you still want to do it programmatically, I think you might be stuck. IIRC the length known by the JIT memory allocator is an overestimate (it's rounded up for alignment), so the disassembler will hit garbage at the end. Reid On Tue, Jul 6, 2010 at 3:07 PM, Bill O'Hara <billtohara at gmail.com> wrote: > Hi, > > With the new llvm-mc code for disassembling, what is the recommended > way to disassemble the final code produced by a JIT compiler backend? > (Eg. in...

...2, 0, [M0] ; C8060202 V_INTERP_MOV_F32 VGPR2, P0, 1, 0, [M0] ; C80A0102 V_INTERP_MOV_F32 VGPR3, P0, 0, 0, [M0] ; C80E0002 EXP 15, 0, 0, 1, 1, VGPR3, VGPR2, VGPR1, VGPR0 ; F800180F 00010203 S_ENDPGM ; BF810000 A less verbose disassembler is included in Mesa for pre-SI clients, so the patch does not embed disassembly for NI or earlier targets. Disassembling during compilation is preferred, as it avoids the overhead of a second LLVM invocation. Further, the SILowerControlFlow pass modifies the input LLVM IR, which makes a second...

hi, i think the current X86 disassembler is quite broken and fails badly on handling REX for x86_64 code. below are some examples: $ echo "0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text por %mm3, %mm0 $ echo "0x40,0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble...

...doing other things for a while, but I have an API patch separated out, which (in addition to being much smaller than past megapatches) corrects two issues Chris identified in his most recent set of patches: - First, it makes the API a good deal simpler. Now, you can instantiate a single MCDisassembler and, each time you want an instruction disassembled, you can simply pass it a MemoryRegion, an offset, and an MCInst to populate. - Second, it adds MCDisassembler to the list of things you can get from a TargetMachine, so you don't have to #include something from lib/ Target/X86 just to...

Hi, I found a mismatch between assembler & disassembler of X86: I assembled an instruction, then disassembled the output, but the result is not the same as the first original code: "add qword ptr [205163983024656], 1" vs " add qword ptr [1985229328], 1" Anybody knows what is wrong? Thanks. $ echo "ADD QWORD PTR [0xba98765432...

...probably doesn't help that I am only familiar with C and Objective-C and find C++ syntax absolutely bewildering. Kind regards, Aidan Steele int main (int argc, const char *argv[]) { LLVMInitializeARMTargetInfo(); LLVMInitializeARMTargetMC(); LLVMInitializeARMAsmParser(); LLVMInitializeARMDisassembler(); const llvm::Target Target; llvm::OwningPtr<const llvm::MCSubtargetInfo> STI(Target.createMCSubtargetInfo("", "", "")); llvm::OwningPtr<const llvm::MCDisassembler> disassembler(Target.createMCDisassembler(*STI)); llvm::OwningPtr<llvm::MemoryBuff...

...> bit > kernel. From the release announcement it looks like llvm-mc isn't > ready for > this purpose yet, was just curious if this kind of task was anywhere > on its > roadmap. Thanks... We don't have anything like that planned, but do plan to do an assembler and disassembler. The disassembler (for x86-16/32/64) is iterating on review comments before it goes in. The assembler is currently being built out and will initially support macho. Translating X86-32 to X86-64 sounds tricky but it could probably be built on some of this infrastructure. -Chris

Hi, just read the LLVM 2.6 release announcement, the bit about llvm-mc caught my attention. I've been looking for a tool to disassemble x86 object files into an IR and then reassemble them into x86_64 object code. The immediate use for them would be to convert driver blobs that some vendors provide for their hardware (e.g. the Lucent modem driver) so they can be used in a 64 bit kernel.