similar to: [LLVMdev] LLVM based interactive disassembler

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/Disassembler/X86DisassemblerDecoder.c 2010-05-06 22:59:00.000000000 +0200

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

I'm having trouble getting TableGen to generate disassembler code. The issue is that I have several TableGen definitions that emit the same instruction encoding. This results in TableGen complaining about encoding conflicts (and not handling those instructions). For example, general purpose registers in the architecture I'm targeting can hold floating point or integer values. As such, I

Hi there. I've looking libcpu project and some history of the mailing list and got a question: what is the status of the disassembler? I mean, is there someone working on it, what targets does it support and so on. I mean, it would be interesting to be able to "undo" the operations LLVM does, like machine code->LLVM IR. If there's no one working with this right now, I'd

Other than the x86 disassembler effort, is there an ARM disassembler effort going on? It seems that there have been commits for weeks with messages like "add so-and-so instruction to ARM.td for disassembly purposes only"... -- Thanks, Shih-wei -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm wondering if anyone is working on a machine code -> LLVM bitcode disassembler? Obviously, there won't be a one-to-one correspondence but it seems like you should be able to get close. There's always inline asm for the remaining fragments. So is there such a thing? Thank you, Bob

Hello, I'm looking for a disassembler to examine a malicious Win32 binary on FreeBSD. Does anybody have any favourites? I see pedisassem in ports, but it looks to be broken and unmaintained (it crashes with a floating point error, currently). MC

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 would like to have more details about this LLVM wished feature (taken from http://llvm.org/OpenProjects.html#misc_new): "Write a disassembler for machine code that would use TableGen to output MachineInstrs for transformations, optimizations, etc." The phrase refers to _native_ machine code? Any extra detail about this feature will be really appreciated, since I'm

Hello I think I found a bug in the x86 instruction definition file, while trying out the disassembler. It looks like the "ADD32rr_alt" instruction should have GR32 operands, not GR16. Attached you can find a patch, which should fix the problem. But even with the change I can not decode e.g. "0x03 0xC1" (should be "addl %ecx, %eax") only if I remove the

Hi, The x86 (32-bit) disassembler can't disassemble any of the following: 0x2b 0xc9 0x8a 0xc8 0xdd 0x04 0x24 These are: subl %ecx, %ecx movb %al, %cl fldl (%esp) I've attached patches to bug#8873 which fix all these issues, but I'm not confident that I've fixed them the right way. The first two problems are caused by the instructions setting 'isCodeGenOnly =

According to http://www.winehq.com/site/docs/winedev-guide/wine-debugger "It seems that Windows Disassembler 32 currently has problems working correctly under Wine, so use IDA or GoVest." I tried it anyway, and it looked ok while it was disassembling my program. But then, when it finished disassembling, the window was made really tiny, and when I made the window regular-sized, the font

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. Currently it does not provide information as to whether a particular bitpattern was UNPREDICTABLE or not. For example, an invalid bitpattern may return correct

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

Hello, I have seen this bug for quite a while, and even in the latest code it is still there: that is X86 disassembler does not handle 0x66 prefix properly, if it is put behind 0xF3 prefix. The below commands should return the same output, but not. $ echo "0xf3 0x66 0xa5"|./build/bin/llvm-mc --disassemble -triple=x86_64 -output-asm-variant=1 .text rep movsw word ptr es:[rdi], word ptr

I was away 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

Hi, By way of example, I have the following instruction: 44 8b 80 c8 03 00 00 movl 968(%rax), %r8d 1) How is this represented in MCInst? 2) Is there information in MCInst that would tell me which bytes of the instruction are responsible for the 968? The reason I am asking is that I want to work with the bytes disassembled/decoded to an instruction at MCInst level.

On Mon, May 23, 2016 at 2:44 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > 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" > >

I attach a patch that fixes this bug. Applies to llvm 3.4svn Please commit it please. Kind Regards James On 13 September 2013 17:46, James Courtier-Dutton <james.dutton at gmail.com>wrote: > Hi, > > I am looking at the "LLVMOpInfoCallback GetOpInfo" callback. > > Example 1 GOOD: > 41 c6 84 24 16 04 00 00 0c : movb $12, 1046(%r12) > > Makes