search for: disasm

...mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, Requires<[In32BitMode]>; This instruction can be REX-prefixed for a 64-bit move, and that also doesn't appear to be defined anywhere. I would file a bugzilla in the x86 component and cc Craig Topper, the x86 disasm/codegen expert. On Wed, Nov 27, 2013 at 8:56 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hi, > > With objdump, i have this (Intel syntax) > > 64 a1 00 00 00 00 mov eax,fs:0x0 > > > However, if I pass above string to llvm-mc, I would have: >...

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to

...ot;, [], IIC_MOV_MEM>, > Requires<[In32BitMode]>; > > This instruction can be REX-prefixed for a 64-bit move, and that also > doesn't appear to be defined anywhere. > > I would file a bugzilla in the x86 component and cc Craig Topper, the x86 > disasm/codegen expert. > > > > On Wed, Nov 27, 2013 at 8:56 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hi, >> >> With objdump, i have this (Intel syntax) >> >> 64 a1 00 00 00 00 mov eax,fs:0x0 >> >> >> However,...

> I would file a bugzilla in the x86 component and cc Craig Topper, the x86 > disasm/codegen expert. If you chase down the revision history, there are already a couple of bugs filed: PR16961 and PR16962. Cheers. Tim.

...Much of it seems fixed already; what's left to fix? The segment prefix override? Does that mean we get to fix disassembly of '0x65 0xa4' while we're at it? (Although we can't even *assemble* that one, I note.) Any comments on the patches I posted on Monday to fix various 16-bit disasm issues? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140115/595a5c6f/attachment.bin>

...://llvm.org/bugs/show_bug.cgi?id=16962#c1 "There are many things wrong with these instructions." :) On Wed, Nov 27, 2013 at 10:17 AM, Tim Northover <t.p.northover at gmail.com>wrote: > > I would file a bugzilla in the x86 component and cc Craig Topper, the x86 > > disasm/codegen expert. > > If you chase down the revision history, there are already a couple of > bugs filed: PR16961 and PR16962. > > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

hi, i found this code in X86DisassemblerDecoder.h #define EA_BASES_32BIT \ ENTRY(EAX) \ ENTRY(ECX) \ ENTRY(EDX) \ ENTRY(EBX) \ ENTRY(sib) \ ENTRY(EBP) \ ENTRY(ESI) \ ENTRY(EDI) \ ENTRY(R8D) \ ENTRY(R9D) \ ENTRY(R10D) \ ENTRY(R11D) \

> As Craig noted: > http://llvm.org/bugs/show_bug.cgi?id=16962#c1 > > "There are many things wrong with these instructions." I think he fixed quite a few of them shortly afterwards (r189201), though obviously not all, as you discovered. Cheers. Tim.

...eft to fix? The segment prefix >> override? Does that mean we get to fix disassembly of '0x65 0xa4' while >> we're at it? (Although we can't even *assemble* that one, I note.) >> >> Any comments on the patches I posted on Monday to fix various 16-bit >> disasm issues? >> >> -- >> dwmw2 >> >> > > > -- > ~Craig > -- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140115/40b33759/attachment.html>

...d Regards James P.S. Example code below: TripleName = "x86_64-pc-linux-gnu"; // Get the target. std::string Error; DecodeAsmX86_64::TheTarget = llvm::TargetRegistry::lookupTarget(TripleName, Error); if (!TheTarget) return 1; ... // Set up disassembler. DisAsm = TheTarget->createMCDisassembler(*STI, *Ctx); if (!DisAsm) return 1; ... // S = DisAsm->getInstruction(*Inst, Size, Bytes_A, PC, // /*REMOVE*/ nulls(), nulls()); // Latest LLVM messes up with the PC set to anything other than zero S = DisAsm->getInstruction(*Inst, S...

Thanks, Luke, for having a look to it. Sure, I can give you some reproducible example -- even in two degrees of completeness ;-): see below. Thanks again, Peter %----------------------------------- (I) first example %----------------------------------- Just to reproduce the error, on r-devel, try: install.packages("RobAStRDA") require(RobAStRDA) getFromNamespace(".RMXE", ns

...or might be whether a call from within your R-devel somehow manages to run an R process with an older R version. Let me know what you find out. luke Here is the little utility, adapted from compiler::disassemble: getbc <- function (code) { .CodeSym <- as.name(".Code") disasm.const <- function(x) if (typeof(x) == "list" && length(x) > 0 && identical(x[[1]], .CodeSym)) disasm(x) else x disasm <- function(code) { code[[2]] <- compiler:::bcDecode(code[[2]]) code[[3]] <- lapply(code[[3]],...

...<< ":\n"; #ifndef NDEBUG raw_ostream &DebugOut = DebugFlag ? dbgs() : nulls(); #else @@ -244,22 +247,22 @@ static void DisassembleObject(const ObjectFile *Obj) { #endif for (Index = Start; Index < End; Index += Size) { MCInst Inst; - if (DisAsm->getInstruction(Inst, Size, memoryObject, Index, + outs() << format("%8x:\t", Index); + if (DisAsm->getInstruction(Inst, Size, memoryObject, Index - SectionVMA, DebugOut, nulls())) { - uint64_t addr; - if (err...

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

...is supported yet. (I think the ^ is > misplaced; it should point to the {rd-sae}.) > > (I may be wrong here but looks like even the X86AsmParser is lacking > support for sae even though some instruction in the .td file contain {sae} > in their asm syntax.) > Oh it seems also the disasm support for sae is lacking: $ echo "62 f1 6c 1e 58 fc"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text <stdin>:1:4: error: invalid input token 62 f1 6c 1e 58 fc I hope there is a plan to o support this SAE stuff soon? Thanks, Jun -------------- next part ---...

...is >> misplaced; it should point to the {rd-sae}.) >> >> (I may be wrong here but looks like even the X86AsmParser is lacking >> support for sae even though some instruction in the .td file contain {sae} >> in their asm syntax.) >> > > Oh it seems also the disasm support for sae is lacking: > > $ echo "62 f1 6c 1e 58 fc"|./Release+Asserts/bin/llvm-mc -disassemble > -triple=x86_64 > .text > <stdin>:1:4: error: invalid input token > 62 f1 6c 1e 58 fc > > > That's not too surprising; assembler and disassembler...

...apstone the ultimate disassembly engine for binary analysis and reversing in the security community. Some known uses of Capstone are automated analysis of binary programs, reverse engineering and static malware analysis. Capstone is a disassembly framework with the target of becoming the ultimate disasm engine for binary analysis and reversing in the security community. Created by Nguyen Anh Quynh, then developed and maintained by a small community, Capstone offers some unparalleled features: - Support multiple hardware architectures: ARM, ARM64 (aka ARMv8), Mips & X86. - Having clean/simple...

...gt;type != P_TEMP) + if (dst && dst->type != P_TEMP) dst = alloc_temp(pc, NULL); /* set.u32 */ set_long(pc, e); e->inst[0] |= 0xb0000000; - e->inst[1] |= (3 << 29); - e->inst[1] |= (c_op << 14); - /*XXX: breaks things, .u32 by default? - * decuda will disasm as .u16 and use .lo/.hi regs, but this - * doesn't seem to match what the hw actually does. - inst[1] |= 0x04000000; << breaks things.. .u32 by default? + e->inst[1] |= 0x60000000 | (ccode << 14); + + /* XXX: decuda will disasm as .u16 and use .lo/.hi regs, but + * that doe...

...!dbg !75 %14 = fadd double %12, %13, !dbg !75 store double %14, double* %3, !dbg !75 ret void, !dbg !76 } !72 = !DILocation(line: 22, column: 11, scope: !65) !73 = !DILocation(line: 25, column: 7, scope: !65) full bitcode: https://gist.github.com/carlokok/aa3fab175f8afe8e4776ad6c2f5cc80a disasm: https://gist.github.com/carlokok/ab265461b37f87a10e0853ffc4d93c77 What could possibly cause this? It's wreaking havoc with the debugger experience. Carlo Kok RemObjects Software

...        Large data types (larger than 4 bytes) are 4-byte aligned.              I didn't yet test this case, but I think here could be the same pitfalls like with orr r0, r0, 4         Register R7 is used as a frame pointer              If I truly understood it's for debug purpose only, but disasmly of my CoreFoundation(ELF) shows r7 usage. Frame pointer on my system is r11.         Register R9 has special usage              Document says r9 could be used since iOS 3.0, and I found a usage in my CoreFoundation. So I don't think it could be a problem. > >> I not yet tested som...