Re: [RFA/RFC] Tweak for a gdb.mi test.

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, May 07, 2002 at 06:50:48PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, May 07, 2002 at 06:09:11PM -0700, Michael Snyder wrote:
> > >
> > > I'm gonna ask for a second pair of eyes, since I don't know MI
> > > very well.
> > >
> > > What this is -- the test is examining the stack, but it is
> > > assuming that main is the last frame.  My change allows for
> > > one extra frame below main (eg. for '_start').
> > >
> > > OK to check in?
> > 
> > Before you check this in, I would prefer to have a policy decision
> > in place about whether we should show that frame or not.  The relevant
> > macro is FRAME_CHAIN_VALID; I believe we should universally (or almost
> > universally) change this to stop at main.  I think that's
> > func_frame_chain_valid but don't trust my memory.
> > 
> > Some ports (HP/UX comes to mind) do wacky things in this macro/method.
> > I'm not sure what they accomplish or whether they are really necessary.
> > Most default to either file_ or func_, and we should standardize that
> > unless there is a good reason not to.
> 
> I don't think we can do that, Daniel -- that would force us to change
> numerous existing target ports.  Retroactive requirements are not
> generally a good idea.  AFAICT, we're stuck with the fact that this
> has not been standardized in the past.  I would guess  that there are
> just as many targets that display the _start frame as don't.

I don't see any argument not to change existing ports, actually.  This
is a behavioral improvement; I think it's a worthwhile one and that it
can't reasonably cause harm.

There are only five targets using custom frame_chain_valid functions;
all the others use a random mix of the five generic versions, some of
which are tangled up with dummy frames.  There are extra sanity checks
on the frame pointer in ARM and d10v and d30v and xstormy16, which
we might want to express independently of the stop-at-main setting;
and I can't even pretend to follow the HPPA version, but again it looks
as if it should be independent of the stop-at-main question.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer