Clicking on 'down one level' results in moving to the older stack frame, wheras
clicking on 'go to bottom of stack' results in moving to the most recent frame.
We should decide whether moving 'down' means moving to a more recent level or to
an old one
I'm not sure what the most precise debugging vernacular is here. I think we
need a ruling from Andrew.
Any comments here Andrew?
Sorry - I meant to create a tracker for this a while ago but forgot.
We'll be keeping the implementation that same, that is, the most recent frame
is at the 'top' of the stack tree. The button 'go to bottom of stack' will
simply be flipped around to 'go to top of stack'
We need to get into contact with the person who made these buttons for this as
well as creating a new button for instruction stepping.
I can expand on the problems, especially the one currently seen in the GI (Gnome
A stack, which consists of a number of frames, has two ends. Each needs a name:
- the frame first created when a program starts running, the oldest frame
- the most recent frame created by the currently running function, the youngest
Problems arise when words such as: inner / outer, top / bottom, up / down, next
/ prev, get used to describe their relationship. And icons such as pointing up
or pointing down to indicate direction.
GDB uses down->to-younger and up->to-older and I'm guessing this is because the
youngest frame is numbered zero and "up" increases the frame number. This,
unfortunatly, has issues:
- a UI that displays the inner most frame at the top gets confusing when "up"
moves the frame "down" (A UI should display the inner most at the top as, by
default scroll bars for long lists start at the top and typically a user wants
the youngest or close to frame
- A UI "up" icon presumably does the "up" command but it will go down and vice-versa
- GDB's backtrace lists frames younger to older yet down goes "up" in that list
And unfortunatly HPD defines "up" and "down" the same way that gdb did; ulgh!
So, I'm sorely tempted to recommend violating the HPD spec, or at least find
better names :-/ and icons :-/
Survey of 16 hackers resulted in 12 wanting "top" youngest, with 4 having no
opinion. "top" is "top".
Yes! One of my oldest unix pet peeves. FWIW the Multics 'probe' debugger made
the oldest frame 0 and each successively newer frame n+1. up in this case went
up the stack. I always found the dbx/sdb/gdb stack numbering method odd.
(In reply to comment #5)
> Yes! One of my oldest unix pet peeves. FWIW the Multics 'probe' debugger made
> the oldest frame 0 and each successively newer frame n+1. up in this case went
> up the stack. I always found the dbx/sdb/gdb stack numbering method odd.
BTW, this "fix" to "up/down", doesn't necessarially imply a re-numbering.
That's a separate problem with an interesting technical hurdle: due to a lack of
reliability of backtraces, always, correctly, and effeciently numbering the
oldest frame #0 isn't possible. For instance, if there's a backtrace failure
the numbering will go all wrong. Should that be changed is, I think, a separate
debate (however I will admit that frame's numbers not changing under ones feet
would make life easier).
*** Bug 5815 has been marked as a duplicate of this bug. ***