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

[Joel Brobecker <brobecker@adacore.com>]

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