On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > > All architectures which support stacktrace carry duplicated code and > > do the stack storage and filtering at the architecture side. > > > > Provide a consolidated interface with a callback function for consuming the > > stack entries provided by the architecture specific stack walker. This > > removes lots of duplicated code and allows to implement better filtering > > than 'skip number of entries' in the future without touching any > > architecture specific code. > > > > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Cc: linux-arch@xxxxxxxxxxxxxxx > > This is a step in the right direction, especially if it allows us to get > rid of the 'skip' stuff. But I'm not crazy about the callbacks. > > Another idea I had (but never got a chance to work on) was to extend the > x86 unwind interface to all arches. So instead of the callbacks, each > arch would implement something like this API: > > > struct unwind_state state; > > void unwind_start(struct unwind_state *state, struct task_struct *task, > struct pt_regs *regs, unsigned long *first_frame); > > bool unwind_next_frame(struct unwind_state *state); > > inline bool unwind_done(struct unwind_state *state); > > > Not only would it avoid the callbacks (which is a nice benefit already), > it would also allow the interfaces to be used outside of the > stack_trace_*() interfaces. That would come in handy in cases like the > ftrace stack tracer code, which needs more than the stack_trace_*() API > can give. I surely thought about that, but after staring at all incarnations of arch/*/stacktrace.c I just gave up. Aside of that quite some archs already have callback based unwinders because they use them for more than stacktracing and just have a single implementation of that loop. I'm fine either way. We can start with x86 and then let archs convert over their stuff, but I wouldn't hold my breath that this will be completed in the forseeable future. > Of course, this may be more work than what you thought you signed up for > ;-) I did not sign up for anything. I tripped over that mess by accident and me being me hated it strong enough to give it at least an initial steam blast. Thanks, tglx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
