This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:sparc/rfc] multi-arch SOFTWARE_SINGLE_STEP et.al.
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [rfa:sparc/rfc] multi-arch SOFTWARE_SINGLE_STEP et.al.
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Mon, 05 Feb 2001 12:09:39 -0800
- CC: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Organization: Red Hat
- References: <3A6A1DF4.C6760CEF@cygnus.com> <3A7E1712.E947C76F@cygnus.com>
Andrew Cagney wrote:
>
> Andrew Cagney wrote:
> >
> > Hello,
> >
> > (I now remember why I kept avoiding this one :-)
> >
> > The attatched multi-arches SOFTWARE_SINGLE_STEP /
> > SOFTWARE_SINGLE_STEP_P. It also does a few other things so watch
> > carefully :-)
> >
> > For the sparc64 this multi-arches software_single_step. Maintainer?
> > Test on a solaris N+1 machine?
>
> And sure enough it broke something :-/
>
> For the sparc64 native, it was selecting software single-step but the
> previous configuration wasn't.
>
> So, for the maintainer. What is correct for these cases?
>
> o sparc32 cross
> was software single step
Should be software single-step.
> o sparc64 cross
> was software single step
Should be software single-step.
> o sparc64 (sol2) native
> was ptrace (hardware) single step
Should NOT be software single-step.
(correction -- procfs, not ptrace. And it's still not really hardware, just OS)
> o sparc32 (sol2) native
> was ptrace (hardware) single step
Should NOT be software single-step.
>
> This kind of highlights the current problems with software_single_step_p
> :-)
Well, but your patch will fix all that, right? ;-)
By the way, Sparc32 must still use software-single-step for Sunos 4 and below.