This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] "single step" atomic instruction sequences as a whole.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: emi-suzuki at tjsys dot co dot jp (Emi SUZUKI)
- Cc: drow at false dot org, schwab at suse dot de, gdb-patches at sourceware dot org
- Date: Thu, 8 Mar 2007 17:15:42 +0100 (CET)
- Subject: Re: [patch] "single step" atomic instruction sequences as a whole.
Emi Suzuki wrote:
> Meanwhile the things about RS6000-AIX came to me: it does not support
> hardware single stepping, so SOFTWARE_SINGLE_STEP_P should always
> return true. My patch has nothing to concern about it...
>
> I have added a new file, tm-rs6000aix.h, to undef SOFTWARE_SINGLE_STEP_P
> for only that target, but felt somewhat strange about the solution.
> I feel like adding some trick for SOFTWARE_SINGLE_STEP_P to gdbarch.c
> rather than undef'ing it, but no idea has come to mind for now.
We're trying to get rid of the tm.h files, and do everything strictly
via the gdbarch callbacks. (This is also necessary for multi-arch
debugging.) I'd much prefer a solution that does not add new tm.h
files (or contents).
Why don't we extend the gdbarch_software_single_step call with a return
value? Common code would call the gdbarch routine, but if it returns
a nonzero value, it will fall back to using hardware single step after
all.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com