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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com