[Lldb-commits] [PATCH] Initial Assembly profiler for mips64
jmolenda at apple.com
Sat Feb 21 13:27:37 PST 2015
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. The ARM64 assembly profiler is a better example of what he wants here.
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.
More information about the lldb-commits