This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc, arm] Always use correct execution state for single-step breakpoints
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: yao at codesourcery dot com (Yao Qi)
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 28 Mar 2011 15:15:42 +0200 (CEST)
- Subject: Re: [rfc, arm] Always use correct execution state for single-step breakpoints
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