When you're talking about compiler generated code, a hand written assembly parser is easy. The complication comes when the compiler changes how it expresses prologues -- or hand written assembly routines.
A simple example for x86_64, you can save a register to the stack with either push %rbx or movq %rax, -0x10(%rbp) (using at&t assembly syntax). If your compiler only does the pushes and that's all you handle, your profiler will fail as soon as it sees the alternate instruction to do the same. You see the assembly profilers like UnwindAssembly-x86 fall over if you don't think up all the instructions that might occur in prologue/epilogues. That's the risk of them. I just looked into the existing arm & arm64 emulation routines and I think I mis-stated what Greg suggested. The arm instruction emulation (see source/Plugins/Instruction/ARM) is a full instruction emulation from the ARM xml instruction description files. It could be a big undertaking. The arm64 instruction emulation (see source/Plugins/Instruction/ARM64) is a hand written emulation of only a dozen different instructions - I hadn't looked into it in detail until now. I think Greg would prefer that the MIPS assembly profiler be written in a similar style to the ARM64 instruction emulation routine. The Instruction plugins are run by the UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp class. This class uses the Instruction subclass to classify the instruction stream and it generates the UnwindPlan from there. For that matter, you could argue that UnwindAssembly-x86 could be rewritten in the same way. I'm less against Greg's suggestion given all of this. It's separating the instruction recognition logic from the UnwindPlan creation logic and seems like a good direction to head in. I haven't done this for the x86 profiler yet myself so I feel bad about asking someone else to jump in here. The "full emulation of the entire ISA is more flexible" argument doesn't hold for something like the EmulateInstructionARM64 class but there is the separation of logic to argue in favor of it. REPOSITORY rL LLVM http://reviews.llvm.org/D7696 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
