search for: mcdisassembler

...y 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 it a MemoryRegion, an offset, and an MCInst to populate. - Second, it adds MCDisassembler to the list of things you can get from a TargetMachine, so you don't have to #include something from lib/ Target/X86 just to...

....h> +#include <llvm/Support/raw_ostream.h> Please use "" instead of <>. You can also just forward declare all these classes instead of #including their headers. +#include "assert.h" Please use the c++ version of c headers when possible: <cassert>. + MCDisassembler(MemoryObject& region, + raw_ostream& vStream) { Please use "foo_t &f" instead of "foo_t& f". + virtual ~MCDisassembler() { + } Make sure each class with a virtual method has at least one method defined out of line: http://llvm.org/docs/Codi...

Hello, After I try making a clean build and got the following error: llvm[3]: Compiling EDDisassembler.cpp for Release build In file included from /llvm/include/llvm/Target/TargetSelect.h:38, from /llvm/lib/MC/MCDisassembler/EDDisassembler.cpp:37: /llvm/stage1/include/llvm/Config/AsmPrinters.def: In function ‘void LLVMInitializeX86TargetAsmPrinter()’: /llvm/stage1/include/llvm/Config/AsmPrinters.def:27: error: redefinition of ‘void LLVMInitializeX86TargetAsmPrinter()’ /llvm/stage1/include/llvm/Config/AsmPrinters.def:27...

...> “DisassemblerLLVMC::DisassemblerLLVMC(const ArchSpec &arch, const char > *flavor_string)”, > > which I couldn’t find if it’s doing correct. Is there a place that > explains the “flavor” and > > “features_str” variables used at DisassemblerLLVMC.cpp:1163 > > (“newLLVMCDisassembler(triple_str, cpu, features_str.c_str(), flavor, > *this)”)? > > > > Another question that I have is, how can I compare the data it gets with > the real instructions? > > I found the file “PPCGenDisassemblerTables.inc”, where the table is > declared, and where the it > &...

...rror: redefinition of 'void LLVMInitializeX86TargetAsmPrinter()' /Volumes/work/gclayton/Documents/src/llvm/include/llvm/Config/AsmPrinters.def:27: error: 'void LLVMInitializeX86TargetAsmPrinter()' previously defined here make[3]: *** [/Volumes/work/gclayton/Documents/src/llvm/lib/MC/MCDisassembler/Release/EDDisassembler.o] Error 1 make[2]: *** [MCDisassembler/.makeall] Error 2 make[1]: *** [MC/.makeall] Error 2 make[1]: *** Waiting for unfinished jobs....

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,

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

...t;devlists at shadowlab.org> wrote: > Hello, > > After I try making a clean build and got the following error: > > llvm[3]: Compiling EDDisassembler.cpp for Release build > In file included from /llvm/include/llvm/Target/TargetSelect.h:38, >                 from /llvm/lib/MC/MCDisassembler/EDDisassembler.cpp:37: > /llvm/stage1/include/llvm/Config/AsmPrinters.def: In function ‘void LLVMInitializeX86TargetAsmPrinter()’: > /llvm/stage1/include/llvm/Config/AsmPrinters.def:27: error: redefinition of ‘void LLVMInitializeX86TargetAsmPrinter()’ > /llvm/stage1/include/llvm/Config/Asm...

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim Grosbach <gros...

[ This question has already been asked in lldb-dev (see attached emails), however it was suggested that I should forward the question to llvm-dev, since it is more relevant to MC Disassembler than LLDB. ] Hello, I am looking for a way to track memory stores and save both the old and the new value of the memory location being modified using LLDB, as described below: 1. Recognize the

...me new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement: [lines 384-386 in HexagonDisassembler.cpp in HEAD] else if (SubregBit) // Subreg bit should not be set for non-doublevector newvalue producers return MCDisassembler::Fail; Where does the requirement come from? Maybe I overlooked it, but I do not see it in the Hexagon V5/V55 Programmer’s Reference Manual. One instruction packet I have encountered in the wild that triggers this failure is: 10: e0 7e df 78 78df7ee0 { r0 = #-9 14: 01 40 91 91 9191...

...variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Hi Jim, > > Thanks for reply. I'm sorry I didn't make myself clear enough. > > The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. > > Thanks, > David > > On Thu, Jun 7, 2012 at 1:27...

...elinked one and have another try. > > I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. > > The ARMMCDisassembler is production quality as be told by Evan. That's why I'm so interested in it. However, I realized today that might not be a good choice. Although the disassembled MCInsts has a clean and simple interface, the op-codes in them are auto generated from instruction description files. They are i...

Hi, Dear LLVM Dev Group, I am doing an LLVM project aimed to disassemble an ARM ELF binary executable to the MCInst format, inserting some instructions or doing some modification, and re-assemble the MCInst to an ELF binary. As I used the llvm-mc, it seems to only have the option "llvm-mc -disassemble", which reads strings and output strings. Is there any command or function that can

...TargetInfo(); LLVMInitializeARMTargetMC(); LLVMInitializeARMAsmParser(); LLVMInitializeARMDisassembler(); const llvm::Target Target; llvm::OwningPtr<const llvm::MCSubtargetInfo> STI(Target.createMCSubtargetInfo("", "", "")); llvm::OwningPtr<const llvm::MCDisassembler> disassembler(Target.createMCDisassembler(*STI)); llvm::OwningPtr<llvm::MemoryBuffer> Buffer; llvm::MemoryBuffer::getFile(llvm::StringRef("/path/to/file.bin"), Buffer); llvm::MCInst Inst; uint64_t Size = 0; disassembler->getInstruction(Inst, Size, *Buffer.take(), 0, llv...

...t;> I'm also looking to turn my MCJIT conversion spike into our main use >> case. The only thing I'm missing is the ability to get a post-linked >> copy of the generated assembly. >> >> In JIT I used JITEventListener's NotifyFunctionEmitted and used a >> MCDisassembler to disassemble the stream (with my own custom >> annotators), and redirected the output to the relevant place for >> auditing of our app. >> >> With MCJIT I notice that NotifyFunctionEmitted is gone >> (understandably) and so I hook NotifyObjectEmitted. I then run thro...

...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 MCInsts, adhering to the abstract base class MCDisassembler (llvm/ MC/MCDisassembler.h). The disassembler is documented in detail in – - lib/Target/X86/X86Disassembler.h (disassembler runtime) - utils/TableGen/X86DisassemblerEmitter.h (table emitter) – as well as in the individual files, functions, and classes. I implemented a use case in tools/llvm-mc/H...

...#39;ll build a non-prelinked one and have another try. I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. The ARMMCDisassembler is production quality as be told by Evan. That's why I'm so interested in it. However, I realized today that might not be a good choice. Although the disassembled MCInsts has a clean and simple interface, the op-codes in them are auto generated from instruction description files. They are i...

Great stuff; thanks both! I'm also looking to turn my MCJIT conversion spike into our main use case. The only thing I'm missing is the ability to get a post-linked copy of the generated assembly. In JIT I used JITEventListener's NotifyFunctionEmitted and used a MCDisassembler to disassemble the stream (with my own custom annotators), and redirected the output to the relevant place for auditing of our app. With MCJIT I notice that NotifyFunctionEmitted is gone (understandably) and so I hook NotifyObjectEmitted. I then run through all the function symbols and dump them a...

...TargetInfo(); LLVMInitializeARMTargetMC(); LLVMInitializeARMAsmParser(); LLVMInitializeARMDisassembler(); const llvm::Target Target; llvm::OwningPtr<const llvm::MCSubtargetInfo> STI(Target.createMCSubtargetInfo("", "", "")); llvm::OwningPtr<const llvm::MCDisassembler> disassembler(Target.createMCDisassembler(*STI)); llvm::OwningPtr<llvm::MemoryBuffer> Buffer; llvm::MemoryBuffer::getFile(llvm::StringRef("/path/to/file.bin"), Buffer); llvm::MCInst Inst; uint64_t Size = 0; disassembler->getInstruction(Inst, Size, *Buffer.take(), 0, llv...