[llvm-dev] Getting MachineInstr opcode mnemonics as strings

Ethan J. Johnson via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 17 09:58:36 PST 2016


On 02/17/2016 12:49 AM, Ahmed Bougacha wrote:
>
> On Tue, Feb 16, 2016 at 9:30 PM, Ethan J. Johnson via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Hello all,
>
>     Is there an easy way to get the human-readable opcode mnemonic
>     (e.g., "MOV32ri64", "CMP32ri8", "JLE_1") for a MachineInstr? I am
>     writing a backend analysis pass for security research, where the
>     idea is for a researcher to examine the output of my pass and
>     identify instructions from it for use in an attack. Right now I'm
>     representing unique instructions with nondescript numeric symbols,
>     like "i28" for the 28th instruction; but it would be nice to give
>     the reader something more helpful like "i28_MOV32ri64".
>
>     MachineInstr doesn't have a getName() function like many other
>     LLVM IR/MachineIR objects; is there anything roughly equivalent to
>     this? I'm already using MachineInstr::print() for debugging
>     output, but it's far too verbose for this purpose. I thought about
>     trying to parse the opcode mnemonic out of the print() output,
>     until I realized just how nasty that would be (not to mention that
>     it prints to a raw_ostream, not an in-memory string).
>
>
> The name (as well as some other information) is in MCInstrInfo; if you 
> have any kind of *InstrInfo (as, e.g., X86InstrInfo isa 
> TargetInstrInfo isa MCInstrInfo), you should be able to do:
>
>   TII->getName(MI->getOpcode());
> -Ahmed

That's exactly what I was looking for - thanks!

Ethan Johnson

-- 
Ethan J. Johnson
Computer Science PhD student, Systems group, University of Rochester
ejohns48 at cs.rochester.edu
ethanjohnson at acm.org
PGP public key available from public directory or on request

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160217/8754e827/attachment.html>


More information about the llvm-dev mailing list