From: Michael Snyder <msnyder@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
Michael Snyder <msnyder@cygnus.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA/RFC] Tweak for a gdb.mi test.
Date: Tue, 07 May 2002 19:15:00 -0000 [thread overview]
Message-ID: <3CD88738.2E9B1BC4@redhat.com> (raw)
In-Reply-To: <3CD887A4.6010605@cygnus.com>
Andrew Cagney 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.
>
> (don't remember which function either, but)
> Yes, I don't think the backtrace should go past main so I think the
> change is wrong.
>
> I remember much debate about the test at the time (it was Cygnus
> internal unfortunatly). The thing that clinched the deal was the
> obeservation (made by a human factors person) that the behavour had to
> be consistent across platforms.
1) It may have to be, but it isn't.
2) Why does it have to be? Lots of behaviors differ between platforms.
3) My real reason for submitting this fix is that it breaks with the
"needs_status_wrapper" change that I submitted the other day.
Of course, technically it would not break if gdb always stopped the
trace at main, but it doesn't...
> For a given OS (e.g. eCos, GNU/Linux,
> ...) the backtrace should look identical, regardless of the ISA.
>
> Having each ISA making independant, and somewhat arbitrary, decisions is
> wrong.
Whether that's so or not, they do. Do you want to have this
always fail for current gdb ports?
> From memory, a suggestion was to let people select the back-trace
> policy independant of the current architecture.
I thought we also had a policy of not inserting tests
that we knew would fail on some targets? Something about
this being a regression test...
Sorry, don't mean to be snippy...
next prev parent reply other threads:[~2002-05-08 2:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-07 18:22 Michael Snyder
2002-05-07 18:30 ` Daniel Jacobowitz
2002-05-07 19:03 ` Michael Snyder
2002-05-07 19:42 ` Daniel Jacobowitz
2002-05-07 19:04 ` Andrew Cagney
2002-05-07 19:15 ` Michael Snyder [this message]
2002-05-07 20:06 ` Andrew Cagney
2002-05-08 13:50 ` Michael Snyder
2002-05-08 15:52 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CD88738.2E9B1BC4@redhat.com \
--to=msnyder@redhat.com \
--cc=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox