This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] frame_id_unwind
- From: Andrew Cagney <cagney at gnu dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 28 Mar 2004 17:31:07 -0500
- Subject: Re: [patch/rfc] frame_id_unwind
- References: <4062EBF9.7040908@gnu.org> <vt24qs8n8gz.fsf@zenia.home>
Can anyone think of a testcase?
However, 'backtrace' won't work right in such a program; if that's
fixed, then this test won't be much of a test any more. Hmm.
Hence the problem, other cases tend to end in a similar dead end.
A thought on the underlying issues:
It seems to me that there are two distinct things being mixed together
here:
One returns a subset of the other.
Wouldn't things work better if we moved the decision about where to
stop displaying the stack into user interface code (I don't know if
there's any place shared by cli and mi, but perhaps one could be
created), and left get_prev_frame as a pure stack-traversal function?
That is, if there exists a next-older frame, get_prev_frame will
return it, whether it's in the user's program or part of the
infrastructure.
frame_unwind_XXX(here) says get me from HERE to XXX via the most
efficient route. It's consistent with the increasingly common
frame_unwind_pc, frame_unwind_register, ...
As for get_prev_frame, I can think of several possibilities:
- publish two interfaces (or parameterize the existing interface)
- change to some sort of iterator
- introduce a new predicate function indicating if the frame is visible
but first, I think the best thing is to eliminate all the almost-dead
code. A quick scan reveals much that can be deleted. Wouldn't happen
own an ns32k ;-)
Andrew