Re: [RFA 5/6] Remove unused variables

["Maciej W. Rozycki" <macro@imgtec.com>]

On Wed, 20 Jul 2016, Paul_Koning@Dell.com wrote:

> > Overall with recent and less so improvements to GCC's and other 
> > compilers' optimizers I think these heuristic unwinders have hardly any 
> > value nowadays, they seem unable to get through function prologues 
> > containing arbitrary instructions thrown there by the scheduler.  This is 
> > very annoying in a common case where you interrupt a debuggee in the 
> > middle of a sleeping syscall, with no way to backtrace through stripped 
> > system shared libraries.
> 
> My experience is that the heuristic unwinders can be made to handle a 
> lot of what's thrown at them now, but it takes quite a lot of extra 
> heuristics to do so.  I have much of this on an internal version.  
> Should I look into making them available?

 Absolutely!

> One thing I've done that may not be generally interesting: make the 
> unwinders work in the kernel (NetBSD) and able to unwind across 
> exception frames so you can use kernel debugging and see the stack all 
> the way into the calling process.  I haven't found this all that 
> interesting in online debugging, but it has sometimes been useful in 
> analyzing kernel crash dumps.

 I think it's a separate matter -- and for post-mortem debugging (and even 
live debugging e.g. with QEMU's integrated debug stub or if you're a lucky 
one who has JTAG probe hardware to hand) you can actually implement an 
exception frame sniffer/unwinder so that GDB can examine it automagically.  
As an example see mips-sde-tdep.c, handling exception frames from the old 
Algorithmics/MTI SDE toolkit/board support package.  If you'd like to add 
a similar handler for the NetBSD kernel, then I'll gladly accept it.

 In a typical user app debug scenario you have cases where you want to 
interrupt the program and see where it is, examine its local state, often 
in the function that made the C library call which ended up in the syscall 
just interrupted.  In the absence of either debug information all the way 
through the syscall's entry point or special support it does not work 
however with ABIs such as these used with the MIPS processor, where the 
structure of the stack frame is variable and you cannot backtrace by just 
taking the value from the frame pointer register and using it recursively 
to fetch previous frame pointers from the stack.

 Unlike say with x86 or Power, where you may not be able to get complete 
information about the innermost or some intermediate frames, but at least 
you can backtrace far enough to reach a frame associated with a function 
from your actual program being debugged and be able to fully examine the 
state there as well as within any previous frames.

 Based on my personal experience with debugging software I think it is a 
serious shortcoming of the MIPS backend, so if you have a way to improve 
the current situation, then by any means please share it and make people's 
life easier.  It'll be a huge step forward even if sometime in the future 
we may get ourselves other means, such as what I have outlined in my 
previous e-mail or maybe yet something else.

  Maciej