This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/rs6000-aix] software_single_step gdbarch method no longer set
- From: Daniel Jacobowitz <drow at false dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 31 Dec 2005 01:00:32 -0500
- Subject: Re: [RFA/rs6000-aix] software_single_step gdbarch method no longer set
- References: <20051231054133.GL4734@adacore.com>
On Sat, Dec 31, 2005 at 09:41:33AM +0400, Joel Brobecker wrote:
> I traced the problem to the following piece of code:
>
> if (from_xcoff_exec)
> {
> /* NOTE: jimix/2003-06-09: This test should really check for
> GDB_OSABI_AIX when that is defined and becomes
> available. (Actually, once things are properly split apart,
> the test goes away.) */
> /* RS6000/AIX does not support PT_STEP. Has to be simulated. */
> set_gdbarch_software_single_step (gdbarch, rs6000_software_single_step);
> }
I have not looked at the patch much (won't this year). However, if
you're feeling especially motivated, we could sidestep this issue...
there's a related cleanup I've been meaning to do for a long while.
The software single step method in the gdbarch is always used if it is
set. But, that doesn't make a lot of sense. The gdbarch method should
mean "software single step is supported"; the predicate "software
single step is required" should live in the target vector instead!
It's a property of the target. e.g. MIPS GNU/Linux doesn't implement
PTRACE_SINGLESTEP, but if you're connected to a kernel debugging
session using a hardware ICE, then maybe you've really got hardware
single step.
It's unfortunately a little trickier than that since remote targets
don't currently report whether using software singlestep is OK :-(
So setting the default behavior may not be simple. I know gdbserver
needs some adjustment here.
Just a thought.
--
Daniel Jacobowitz
CodeSourcery, LLC