On Fri, Oct 16, 2020 at 01:15:34PM +0100, Mark Brown wrote: > > Yes, exactly - just copying the existing implementations and hoping that > it's sensible/relevant and covers everything that's needed. It's not > entirely clear what a reliable stacktrace is expected to do that a > normal stacktrace doesn't do beyond returning an error code. While in the end there may not be much of a difference between normal and reliable stacktraces beyond returning an error code, it still requires beefing up the unwinder's error detection abilities. > > > The searching for a defined thread entry point for example isn't > > > entirely visible in the implementations. > > > For now I'll speak only of x86, because I don't quite remember how > > powerpc does it. > > > For thread entry points, aka the "end" of the stack: > > > - For ORC, the end of the stack is either pt_regs, or -- when unwinding > > from kthreads, idle tasks, or irqs/exceptions in entry code -- > > UNWIND_HINT_EMPTY (found by the unwinder's check for orc->end. > > > [ Admittedly the implementation needs to be cleaned up a bit. EMPTY > > is too broad and needs to be split into UNDEFINED and ENTRY. ] > > > - For frame pointers, by convention, the end of the stack for all tasks > > is a defined stack offset: end of stack page - sizeof(pt_regs). > > > And yes, all that needs to be documented. > > Ah, I'd have interpreted "defined thread entry point" as meaning > expecting to find specific functions appering at the end of the stack > rather than meaning positively identifying the end of the stack - for > arm64 we use a NULL frame pointer to indicate this in all situations. > In that case that's one bit that is already clear. I think a NULL frame pointer isn't going to be robust enough. For example NULL could easily be introduced by a corrupt stack, or by asm frame pointer misuse. -- Josh
