Re: [patch/rfc] frame_id_unwind

[Andrew Cagney <cagney@gnu.org>]

>>> 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