Bug 3459 - The concept of moving 'up' or 'down' in a stack frame is inconsistent
Summary: The concept of moving 'up' or 'down' in a stack frame is inconsistent
Status: RESOLVED FIXED
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Adam Jocksch
URL:
Keywords:
Depends on: 5815
Blocks: 1633
  Show dependency treegraph
 
Reported: 2006-11-05 20:26 UTC by Adam Jocksch
Modified: 2008-03-03 14:09 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jocksch 2006-11-05 20:26:40 UTC
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
Comment 1 Rick Moseley 2006-11-06 13:34:15 UTC
I'm not sure what the most precise debugging vernacular is here.  I think we
need a ruling from Andrew.

Any comments here Andrew?
Comment 2 Mike Cvet 2006-11-06 14:33:44 UTC
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.
Comment 3 Andrew Cagney 2006-11-08 17:01:12 UTC
I can expand on the problems, especially the one currently seen in the GI (Gnome
Interface).

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
through to:
- the most recent frame created by the currently running function, the youngest
frame

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 :-/
Comment 4 Andrew Cagney 2006-11-09 15:43:50 UTC
Survey of 16 hackers resulted in 12 wanting "top" youngest, with 4 having no
opinion.  "top" is "top".
Comment 5 Stan Cox 2006-11-09 16:26:07 UTC
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.

Comment 6 Andrew Cagney 2006-11-09 16:46:48 UTC
(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).


Comment 7 Andrew Cagney 2008-03-03 14:09:20 UTC
*** Bug 5815 has been marked as a duplicate of this bug. ***