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

Ulrich Weigand
2011-03-28T13:16:00Z

Yao Qi wrote:
> On 03/25/2011 02:31 AM, Ulrich Weigand wrote:
> > +void
> > +arm_insert_single_step_breakpoint (struct gdbarch *gdbarch,
> > + struct address_space *aspace,
> > + CORE_ADDR pc)
> > +{
> > + struct cleanup *old_chain
> > + = make_cleanup_restore_integer (&arm_override_mode);
> > +
> > + arm_override_mode = IS_THUMB_ADDR (pc);
> > + pc = gdbarch_addr_bits_remove (gdbarch, pc);
> > +
> > + insert_single_step_breakpoint (gdbarch, aspace, pc);
> > +
> > + do_cleanups (old_chain);
> > +}
> > +
>
> I don't understand why we put make_cleanup_restore_integer/do_cleanups
> in the same function. Can't we use a temp variable to save/restore the
> value of arm_override_mode?

To ensure that the variable is always reset, even if
insert_single_step_breakpoint throws an exception.

> > +
> > +gdb_exit
> > +gdb_start
> > +gdb_reinitialize_dir $srcdir/$subdir
> > +gdb_load ${binfile}
> > +
>
> `clean_restart' can do these four above.

Yes, I guess so ... I was copying an old test case.

> > +if ![runto_main] then {
> > + gdb_suppress_tests
> > +}
>
> 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.