Just thinking outloud here, might not implement this for a while, but...
In terms of reverse engineering LOS, I think I want to add something to keep track of stack frames, and especially the parameters pushed to the stack before any LINE10, TRAP, JSR/BSR and procedure calls. I might or might not need to deal with A7/A6 stack frames, when they're used, but likely keeping track of the changes to A7 will be good enough.
The most common pattern will be that A7 will be stable for the duration of the function/procedure, except right when we're about to call something, then items will be pushed to the stack (so A7 will decrease for 2-3 opcodes in a row), then the call will happen, on the flip side of the call, items will be pulled off the stack (or accessed relative to A7 without changing it), then for the remainder of the routine, it will stay stable, and then at the end reset to what they were before the call. So this is mostly about detecting stable A7 vs rapid changes and then a trap/call and logging that. (This won't work for things like TRAP 7 where registers are used as parameters.)
Trouble is that there's a few flavors of these in the various ABIs, so will need to detect them all, and I don't know what (eventually I'll have to deal with) UniPlus/Xenix will need there, so that code will need to be flexible.
I'll also need to figure out the PID equivalent for whatever process is currently running. I can use MMU context as a proxy for this with 0 as the OS, and 1,2,3 as upto 3 tasks, but then when LOS switches past 3 concurrent processes I'll need to know which I'm looking at, so that means maintaining separate stack trace logs for each running process, so I'll need to reverse engineer whatever PID equivalent is as well.
tl;dr This will help illuminate parameters passed to these unknown routines. This will also help with the debugger effort as it will provide similar functionality to the bt (backtrace) command in gdb.
