Debugging stack frames on SPARC platforms

[Clay McClure <clay at daemons dot net>]

Hello,

I've been debugging an UltraSPARC application running on Solaris 2.6 and I'm
trying to understand how GDB interacts with register windows and the stack.

When I step through the program and encounter a SAVE instruction, I notice
that the current window pointer (CWP) is not decremented by 1 (mod NWINDOWS)
as I would expect. Rather, it seems to be decremented by 2 (I'm not sure of
this, I'm trying to recall what I saw a few days ago). Is GDB manipulating
the CWP or am I seeing a side-effect of kernel trap handling?

Secondly, when querying the registers I've noticed that the window invalid
mask (WIM) is always 0x0. I would expect at least one bit to be set, marking
the window reserved for kernel trap handlers. Does GDB clear the WIM, or is
Solaris clearing it?

And finally, looking through the stack I've noticed that the local and in
registers have been saved to memory every time a subroutine is called. I'm
trying to understand the conditions that cause the kernel to save a register
window to the stack, and have come up with three scenarios:

    1 - A SAVE instruction requests a new window, but the next window is
marked invalid and the kernel window overflow trap handler is called, saving
the CWP+2 (mod NWINDOWS) window to the stack (at the address pointed to by
%sp in the window to be saved),

    2 - A context switch occurs, causing the kernel to save all windows of
the current process to the stack and reload all windows of the newly
scheduled process from the stack,

    3 - The kernel returns control of a traced process to GDB, and flushes
all windows to the stack to facilitate debugger tracebacks (or as part of
the context switch mentioned above).

Are there other scenarios where the os might save register windows to the
stack? And is there a way to observe register windows as they would behave
if the process were not being run under GDB?


Cheers,

Clay