similar to: X86 disassembler fails to handle 0x66 prefix?

On Wed, Dec 24, 2014 at 2:43 PM, Craig Topper <craig.topper at gmail.com> wrote: > I believe this particular error is caused by this. That seems easy enough > to just drop the bit. Do you have other non-mmx examples? > > case TYPE_MM: \ > if (index > 7) \ > *valid = 0;

I looked at this briefly, I think it causes some mistakes that get reversed later in fixupReg. The disassembler design is a bit of a mess with regards to prefixes and operand size. On Tue, Apr 1, 2014 at 4:43 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > On Mon, Mar 31, 2014 at 11:48 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hi, >> >>

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

The IMM3/IMM5 come from here X86RecognizableInstr.cpp 943 TYPE("SSECC", TYPE_IMM3) 944: TYPE("AVXCC", TYPE_IMM5) On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> hi, >> >> some instructions

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

hi, some instructions mismatch between assembler & disassembler, like below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $

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

There is a problem on X86 disassembler for instructions beginning with x86 prefix : $ echo "0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble movdqa (%edi), %xmm1 $ echo "0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble pushl %ebx <stdin>:1:6: warning: invalid instruction encoding 0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00

On Thu, Jun 26, 2014 at 10:23 AM, Adam Nemet <anemet at apple.com> wrote: > > > On Jun 25, 2014, at 7:05 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > > On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > >> Hi Jun, >> >> On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: >>

Hello Daniel, At the moment we are preparing the patch for disassembling microMIPS 16 bit instructions and it will be on Phabricator tomorrow or on Wednesday. Functionality is implemented in MipsDisassembler::getInstruction where first two bytes are read and decodeInstruction is called with DecoderTableMicroMips16 and only if it fails we read 4 bytes and call decodeInstruction with

On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > Hi Jun, > > On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > Hi, > > > > I am trying to assemble below instruction with latest LLVM code, but > fail. Am I doing something wrong, or is this a bug? > > > > > > $ echo "vaddps zmm7

Hi, In file X86DisassemblerDecoder.c, we have function readPrefixes() with below code: ..... } else if (insn->mode == MODE_32BIT) { insn->registerSize = (hasOpSize ? 2 : 4); insn->addressSize = (hasAdSize ? 2 : 4); insn->displacementSize = (hasAdSize ? 2 : 4); insn->immediateSize = (hasOpSize ? 2 : 4); } .... This is confused to me: so we

On Tue, Oct 9, 2012 at 9:25 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > On Fri, Oct 5, 2012 at 3:45 PM, Jun Koi <junkoi2004 at gmail.com> wrote: >> On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall >> <David.Chisnall at cl.cam.ac.uk> wrote: >>> On 5 Oct 2012, at 08:34, Jun Koi wrote: >>> >>>> any idea on how to fix the problem?

Hi, We have this line in micromips-16-bit-instructions.s # CHECK-EB: addu16 $6, $17, $4 # encoding: [0x07,0x42] However, when I check this with llvm-mc, like below, I dont get back the assembly. This is against the latest LLVM code. What is wrong here? Thanks, Jun $ echo "0x07,0x42"|./Release+Asserts/bin/llvm-mc -disassemble -triple=mips -show-encoding -mattr=micromips

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

currently, there is no (easy) way to set the AssemblerDialect. the only method i am aware of is to set that via cl:opt. this patch fixes that by adding a public function setAssemblerDialect() to class MCAsmInfo. Signed-off-by: Jun Koi <junkoi2004 at gmail.com> diff --git a/include/llvm/MC/MCAsmInfo.h b/include/llvm/MC/MCAsmInfo.h index 97aad71..cd08a7e 100644 ---

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, there are two arrays named DecoderTable32[] and DecoderTable16[] that has no reference to. any idea why they are there? does it make sense to remove them? (this is llvm 3.3) thanks, Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130823/a95811fb/attachment.html>

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

Hi, It seems LLVM-MC is broken with Avx512? $ echo "vinserti32x4 \$1, %xmm21, %zmm5, %zmm17"|./Release+Asserts/bin/llvm-mc -assemble -arch=x86-64 -show-encoding -x86-asm-syntax=att .text vinserti32x4 $1, %xmm21, %zmm5, %zmm17 # encoding: [0x62,0xa3,0x55,0x48,0x38,0xcd,0x01] $ echo "0x62,0xa3,0x55,0x48,0x38,0xcd,0x01" |./Release+Asserts/bin/llvm-mc -disassemble