[Lldb-commits] [PATCH] Initial Assembly profiler for mips64

[Greg Clayton]

> On Feb 21, 2015, at 1:27 PM, Jason Molenda <jmolenda at apple.com> wrote:
> 
> I think you're making the same mistake I made initially when Greg proposed "instruction emulation".  This can mean two things:
> 
> 1. Full emulation of the entire instruction set by the Instruction plugin, with flags to indicate instructions that are relevant to prologue/epilogue analysis.
> 2. Emulation a half dozen instructions used in prologues/epilogues, ignoring all the others and assuming they don't do anything related to unwinding.
> 
> In both cases, the EmulateInstruction plugin marks up attributes about the instructions ("This instruction just saved a register on the stack", "this instruction just changed the stack pointer").  Another architecture-independent class, UnwindAssemblyInstEmulation, uses these attributes and generates an UnwindPlan.
> 
> Greg's suggestion to write the MIPS assembly profiler is suggesting approach #2 above.  He isn't looking for full ISA emulation like we happen to do for ARM.

We actually don't do all instructions for ARM, it is just because the PC can be used as a GPR for add/sub/store/load etc that we had to cover all instructions that could modify the PC. We definitely don't cover all, but we do cover all that can modify the PC.


>  The ARM64 assembly profiler is a better example of what he wants here.

Yep, sorry I wasn't clear on this, just emulate instructions that are commonly used in prologue/epilogue code that add/sub from the SP and push callee saved registers. Should be 5-15 instructions max. And it puts it in code that can then be re-used elsewhere. One of the big problems in GDB code was duplicated code that pulls apart instructions. Skip prologue would have its own copy, parse prologue would have its own separate copy. This made it a nightmare to upkeep the code as you would have to go find all these magic places people were pulling apart instructions and find and fix all of them.
> 
> The UnwindAssembly-x86 class mixes the architecture specific instruction matching and the UnwindPlan generation together.  He wants to see a separation of the architecture specific bits and the architecture independent bits, that's all.
> 
> The only hiccup to this, my only reluctance to push for this wholeheartedly, is that UnwindAssemblyInstEmulation *should* be architecture independent but to-date it has only been used for arm & arm64.  It may have assumptions about the way those architectures set up/tear down stack frames.
> 
> It would be interesting to rewrite UnwindAssembly-x86 in the instruction emulation style to shake out any arm assumptions in UnwindAssemblyInstEmulation -- and when I say write it in instruction-emulation style, I don't mean adding any additional instructions, just the dozen insns it knows about today.  But it'll be a little while before I have free time to do that myself.
> 

The EmulateInstruction can claim it supports the following:

//------------------------------------------------------------------
/// Instruction types
//------------------------------------------------------------------    
typedef enum InstructionType
{
    eInstructionTypeAny,                // Support for any instructions at all (at least one)
    eInstructionTypePrologueEpilogue,   // All prologue and epilogue instructions that push and pop register values and modify sp/fp
    eInstructionTypePCModifying,        // Any instruction that modifies the program counter/instruction pointer
    eInstructionTypeAll                 // All instructions of any kind

}  InstructionType;
    

Usually eInstructionTypePrologueEpilogue and eInstructionTypePCModifying are very easy to implement for a given architecture. eInstructionTypePrologueEpilogue is the important one to support when writing the EmulateInstruction for Unwind.

Greg