Friendly stack/locals view

[Daniel Santos]

I've proposed this idea to the gdb bug database (as an enhancement), but I've
got some UI ideas that I would I would run by you guys.  As you know, it's
quite often necessary to when debugging to view memory and often the stack --
especially whey trying to debug from the assembly level and mapping stack
pointer offsets to locals, etc.  I never did real x86 programming, the only
assembly I did was on the Motorola 65xx series (thus dating myself!).

Basically, I would like to see a view of the stack that provides both the raw
data and friendly interpretations of what that data represents.  This would
be similar to the "Variables" window, or could even be an enhanced view of
it.  It would be a table view with the following columns

* sp offset
* raw bytes + optional ascii text
* local name
* value

Here is a more detailed description (well, I guess it's more of a
specification now) of my idea.

Descriptions of Columns
=======================

SP Offset
---------
This should be the offset from the sp register where the local is stored
(probably allow the hex/decimal setting to dictate how it's rendered)

Raw Bytes
---------
This is the raw bytes displayed in hex, like in the memory window.  I would
say that it should initially be wide enough to display either either 4 or 8
bytes, but as with any descent widget, the actual width is adjustable (like
they are now in the "Variables" window now).  If the raw bytes column is too
narrow to display all of the bytes, some type of [+] button/widget should be
available to allow the user to expand it and display all of the bytes used
for that variable by increasing the height of the row (leaving all other
fields aligned to the top of their respective cells).  Finally, if a setting
is enabled, the Raw Bytes field will display the ascii text for each of the
bytes to the right.  If the field is too narrow and has been expanded, then
the characters should match the hex values displayed on that row in the field
(i.e., just like the canonical hex/ascii views).

Local Name
----------
This is the name of the local variable

Value
-----
This is the pretty value (formatted via gdb's "print" or something)

Configuration Settings
======================

Boolean: Display Text
---------------------
If enabled, an ascii text representation of the raw bytes is included after
the raw bytes (as described above).

Boolean: Display all frames
---------------------------
Normally, the window should only display locals from the current/selected
frame.  Enabling this setting (probably best as right click and check a menu
checkbox item), then all frames of the selected thread are displayed.  Thus,
the view would have it's column headings, but like the Variables window
having expandable "Local" and "Watch" items in a treeview, this could have
each stack frame as expandable.  Initially, all frames except for the current
should be collapsed.  Once you expand the frame, you see the stack view as
described above.  Something like:

[+] #0 main        main.c:42
[-] #1 myfunc      main.c:80
   sp+0x00  01 00 00 00 jack  1
   sp+0x03  ad be ef de myptr 0xdeadbeef

Boolean: Display All Threads
----------------------------
Same as displaying all frames, except that the tree view gains a level of
depth.  Initially, all threads except for the current thread should be
collapsed.  e.g.: 

[-] Thread 1
    +[+] #0 main        main.c:42
    +[-] #1 myfunc      main.c:80
    |   sp+0x00  01 00 00 00  jack  1
    |   sp+0x03  ad be ef de  myptr 0xdeadbeef
    +[-] #2 myfunc2     main.c:100
        sp+0x00  20           c ' '
[+] Thread 2
[+] Thread 3

Boolean: Display All Stack Data
-------------------------------
Normally, the view should display only local variables.  If this option is
enabled, it should display all stack data and describe it, like labling which
registers for the previous frame are stored where, etc.  Because I don't have
a indepth understanding of x86 assembly and the various calling conventions,
I can't elaborate with descent examples.  But basically, anything that isn't
linked to an element of the high level language should be displayed if this
setting is enabled and not displayed otherwise.  As I understand it (very
high level) when a function is called, all or most of the registers are
pushed on the stack and when the "call" instruction is executed that the
processor pushes the pc on the stack as well.  I'm exceedingly foggy on the
details, but it would be nice to be able to display these.  I could see this
as being very helpful for isolating various stack corruption issues,
especially when the hex values are quickly recognized (i.e., are common like
if you recognize that the stack data that used to be register values from the
previous frame is actually text that you regognize from or your program or a
common value, it's a quick

Final Notes
===========
Obviously, the ability to click the [+] on existing variables that are
arrays, objects or pointers is invaluable and should be preserved in this
view.  I suppose it could also be helpful to do something similar with
"watched" values, but the "SP Offset" field couldn't be used as described
above.  Instead, it would have to be replaced with an "Address" field (or
some such name) and the values for locals be displayed as "sp+<offset>",
(e.g., "sp+0x00") and for watched as an absolute address (or perhaps even
relative to ds where applicable?  I dunno this part that well, whatever is
most helpful)

I think that this would not only add a lot of aid to debugging, but will
actually help many programmers better understand how the C or C++ compiler
has dealt with their data, which would quite a nice side effect IMHO. :)  So
I guess in essence, this is like a hybrid backtrace-locals (and possibly
watched variables)-threads-memory type of view.

Daniel