similar to: [LLVMdev] New ARM disassembler - unpredictable instructions

Hi James, On Aug 12, 2011, at 1:02 AM, James Molloy wrote: > I’ve got a load of examples for this, but I’ll pick one. > > echo '0xB0 0x00 0x00 0x00' |/work/llvm-cmake2/build/bin/llvm-mc -arch arm --disassemble – > strheq r0, [r0], -r0 > > This instruction encoding is marked UNPREDICTABLE. The question is: does a disassembly of it have value? One use case put

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

Hi, What does llvm use for testing. The area of testing I am interested in are how to test the accuracy of the assembler/disassembler. So, if you take an IR level instruction. How do you verify that the generated CPU specific instruction is correct? Is there an automated method for this? I wish to implement automated testing on a decompiler I am writing, and thought that the test methods used in

Hello everyone At EuroLLVM I presented some testing work we have been doing on improving correctness of the MC Layer for ARM. There seemed to be interest from the community in seeing the results of this test suite. Background ----------- We are using a test suite, called MC Hammer, that compares MC with an ARM in-house implementation of the same functionality. The test space for this suite is

Hello. Sometimes the constraints imposed on an instruction's encoding are too complex to be described in tablegen alone. In such cases a custom decoder method is implemented. This makes sense when the decoding itself is very complex, but it is wasteful to do it only when checking additional constraints. This is because: 1. a custom decoder method has to decode operands, set opcodes, etc. -

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

Hi Mihail, > static DecodeStatus CheckNEONConstraint(const MCInst &Inst, unsigned Insn) [...] > ConstraintCheckMethod = "CheckNEONConstraint" In general I like the idea of an instruction-validation method. I think it could also potentially solve the SoftFail/UNPREDICTABLE issues that are looming (and partially resolved for decoding at present). However, I think that to cope

Hello all, I would like to assign some bits in the instructions, based on the order of mnemonics that appear in a special order. I can do it in TableGen itself, but it will not be well maintainable based on the things I want to accomplish. Therefor, I would like to do it in the c++ file which is waaay easier (at least in the concept!!). Imagine I have this in my base class in TableGen:

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.

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.

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

Thanks for all the hints everyone. Based on your suggestion, O.J., I've added code to toy.cpp from the tutorial to disassemble. ready> 1+1; ready> movabsq $140737353367568, %rax movsd (%rax), %xmm0 ret Evaluated to 2.000000 ready> Which looks correct by inspection - printing the byte array to stdout and feeding it to llvm-mc offline produces the same code as one would also

Bill, thanks for your comments. I'll respond to them individually. I've attached a new revision of the patch that addresses them. Patch built and tested against SVN 79487, with the additional attached fix that fixes an Intel table bug. Sean On 2009/08/18, at 0:57, Bill Wendling wrote: > 0. Watch out for tabs! Fixed. Thanks. > 1. Includes like this "#include

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 Bill, I'm coincidently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is

If you're on a recent flavor of Linux, you may be able to just go into gdb and type "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

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:

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

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 -triple=x86_64 .text por %mm3, %mm0 $ echo

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 [0xba9876543210], 0x1"|llvm-mc -assemble