Re: [rfc, arm] Always use correct execution state for single-step breakpoints

Joel Brobecker
2011-03-28T17:11:29Z

> > > +if ![runto_main] then {
> > > + gdb_suppress_tests
> > > +}

We decided a long time ago that gdb_suppress_entire_file,
gdb_suppress_tests et al should no longer be used...

> > I am OK with part, but a question on general handling `failed to
> > runto_main'. I noticed there are some different policies to handle
> > that, such as `fail and return', `perror and return', and
> > 'gdb_suppress_tests'. Which on is recommended?
>
> I don't really have a strong opinion on that, except that perror is
> probably wrong (this is supposed to be uses to signal problems in
> the test *framework* itself). I'd say that if there is a reasonable
> expectation that starting up the test may fail on some platforms,
> a failure of runto_main ought to trigger something like UNTESTED
> or UNSUPPORTED. Otherwise it should trigger a FAIL.

What we document right now is:

if ![runto_main] {
return -1
}

(http://sourceware.org/gdb/wiki/GDBTestcaseCookbook)

We might have discussed it, but I'm not sure. I see your point
about posting an UNTESTED OR UNSUPPORTED, which I think
prepare_for_testing does. In fact, an old message (from
most likely DanielJ, in 2006):

> I've been using untested followed by return. Why wouldn't that be
> ideal?

So, if that's agreeable to everyone, I will change the Cookbook
to follow that.

--
Joel