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

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

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

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

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

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

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > 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. Thanks Sean, comments below. Are you sure you attached the updated patch? I

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

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.

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

Cool. I've almost done the disassembly part. Any hint on how to translate from MCInst to ELF binary? E.g., which LLVM tool to use? I only find tools effective on LLVM Bitcode. Thanks so much again. On Wed, Sep 18, 2013 at 7:48 PM, James Courtier-Dutton < james.dutton at gmail.com> wrote: > How about: > http://blog.llvm.org/2010/01/x86-disassembler.html > > This is what

On Wed, Oct 09, 2013 at 08:06:42PM -0500, Jay Cornwall wrote: > Hi, > > This patch adds R600/SI disassembly text to compiled object files, when > a code dump is requested, to assist debugging in Mesa clients. > > Here's an example of the output in a Mesa client with a corresponding > patch and RADEON_DUMP_SHADERS set: > > Shader Disassembly: > >

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 James, Not sure if you've already found the problem but I've been looking at this issue a bit as a way to learn. What I've seen is that the wrong operand names are used for the instruction which causes the decoder emitter to fail to recognize the operands. The attached patch changes the names of the operands and adds a test for the disassembly of the instruction. I haven't

Hi Sean, > the attached diff implements a table-driven disassembler for the X86 > architecture (16-, 32-, and 64-bit incarnations), integrated into > the MC framework. The disassembler is table-driven, using a custom > TableGen backend to generate hierarchical tables optimized for fast > decode. The disassembler consumes MemoryObjects and produces arrays > of

I'll look into it, thanks for the report. On Thu, Jul 30, 2015 at 11:01 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Any ideas on this bug? > > Thanks. > > > On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hello, >> >> There is an issue in the latest Sparc code: while we can encode POPC, >> decode

Any ideas on this bug? Thanks. On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hello, > > There is an issue in the latest Sparc code: while we can encode POPC, > decode results in crash in llvm-mc > > $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble > -triple=sparcv9 -show-encoding > .text > popc

Hello, There is an issue in the latest Sparc code: while we can encode POPC, decode results in crash in llvm-mc $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble -triple=sparcv9 -show-encoding .text popc %g1, %g2 ! encoding: [0x85,0x70,0x00,0x01] $ echo "0x85,0x70,0x00,0x01"|./Release+Asserts/bin/llvm-mc -disassemble -triple=sparcv9

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > Hi Sid, > > This feels like it’s exposing too much of the disassembler internals > into the MCOperand representation. I’m not sure I follow why that’s > necessary. Can you elaborate a bit? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

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