Powerpc and software single step

Powerpc and software single step

[Jimi Xenidis]

The AIX kernel does not support single step but the Linux kernel does.

However, I am working with a remote machine level debugger for PowerPC
that allows me to debug a running Linux kernel and cannot support
single stepping.  For this I require that when debugging a Linux
target I need to turn on SOFTWARE_SINGLE_STEP.
 
I would like to add this to an "obscure" setting that will turn it on
even under Linux.
Here is the patch.. please accept, feel free to mangle the symbol
names to taste.

-JX

diff -Naur -X ./Xdiff src/gdb/config/powerpc/tm-linux.h mygdb/gdb/config/powerpc/tm-linux.h
--- src/gdb/config/powerpc/tm-linux.h	Thu Jun 12 19:58:07 2003
+++ mygdb/gdb/config/powerpc/tm-linux.h	Tue Aug 12 09:05:02 2003
@@ -33,9 +33,11 @@
 
 /* We can single step on linux */
 #undef  SOFTWARE_SINGLE_STEP
-#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
+extern void ppc_linux_software_single_step (enum target_signal, int);
+#define SOFTWARE_SINGLE_STEP(sig,bp_p) ppc_linux_software_single_step (sig, bp_p)
 #undef  SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
+extern int ppc_linux_single_step_mode;
+#define SOFTWARE_SINGLE_STEP_P() ppc_linux_single_step_mode
 
 /* Make sure nexti gets the help it needs for debugging assembly code
    without symbols */
diff -Naur -X ./Xdiff src/gdb/ppc-linux-tdep.c mygdb/gdb/ppc-linux-tdep.c
--- src/gdb/ppc-linux-tdep.c	Tue Jun 24 19:09:22 2003
+++ mygdb/gdb/ppc-linux-tdep.c	Tue Aug 12 09:22:11 2003
@@ -1075,10 +1075,35 @@
     }
 }
 
+int ppc_linux_single_step_mode = 0;
+void
+ppc_linux_software_single_step (enum target_signal sig , int bp_p)
+{
+  if (ppc_linux_single_step_mode)
+    {
+      rs6000_software_single_step (sig, bp_p);
+    }
+  else
+    {
+      internal_error (__FILE__, __LINE__, "Will never execute!");
+    }
+}
+
 void
 _initialize_ppc_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_powerpc, 0, GDB_OSABI_LINUX,
 			  ppc_linux_init_abi);
   add_core_fns (&ppc_linux_regset_core_fns);
+
+  add_show_from_set (add_set_cmd("single-step-mode", class_obscure,
+				 var_integer,
+				 &ppc_linux_single_step_mode, "\
+Set single step mode for PowerPCtarget:\n\
+  0 = Target supports single stepping (i.e. Linux)\n\
+  1 = Target does not support single stepping (i.e. AIX, Simulators).",
+				 &setlist),
+		     &showlist);
 }
+
+

Re: Powerpc and software single step

[Kevin Buettner]

On Aug 12,  6:31pm, Jimi Xenidis wrote:

> The AIX kernel does not support single step but the Linux kernel does.
> 
> However, I am working with a remote machine level debugger for PowerPC
> that allows me to debug a running Linux kernel and cannot support
> single stepping.  For this I require that when debugging a Linux
> target I need to turn on SOFTWARE_SINGLE_STEP.
>  
> I would like to add this to an "obscure" setting that will turn it on
> even under Linux.
> Here is the patch.. please accept, feel free to mangle the symbol
> names to taste.

The patch looks mostly okay to me.  I do have some comments and questions
though...

1) It is customary to provide ChangeLog entries with patch submissions.

2) Why is ``ppc_linux_single_step_mode'' an extern in tm-linux.h?  I
   would really prefer that it be local to ppc-linux-tdep.c.  If
   there's some compelling reason for it to not be local, then we can
   discuss adding it to ppc-tdep.h.

3) Is a copyright assignment needed for this patch?

   [ This question is not just for Jimi, but for others reading this
   list as well.  I'm leaving Jimi's patch quoted below so that others
   can look without having to dig up the original patch submission.  ]


> diff -Naur -X ./Xdiff src/gdb/config/powerpc/tm-linux.h mygdb/gdb/config/powerpc/tm-linux.h
> --- src/gdb/config/powerpc/tm-linux.h	Thu Jun 12 19:58:07 2003
> +++ mygdb/gdb/config/powerpc/tm-linux.h	Tue Aug 12 09:05:02 2003
> @@ -33,9 +33,11 @@
>  
>  /* We can single step on linux */
>  #undef  SOFTWARE_SINGLE_STEP
> -#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
> +extern void ppc_linux_software_single_step (enum target_signal, int);
> +#define SOFTWARE_SINGLE_STEP(sig,bp_p) ppc_linux_software_single_step (sig, bp_p)
>  #undef  SOFTWARE_SINGLE_STEP_P
> -#define SOFTWARE_SINGLE_STEP_P() 0
> +extern int ppc_linux_single_step_mode;
> +#define SOFTWARE_SINGLE_STEP_P() ppc_linux_single_step_mode
>  
>  /* Make sure nexti gets the help it needs for debugging assembly code
>     without symbols */
> diff -Naur -X ./Xdiff src/gdb/ppc-linux-tdep.c mygdb/gdb/ppc-linux-tdep.c
> --- src/gdb/ppc-linux-tdep.c	Tue Jun 24 19:09:22 2003
> +++ mygdb/gdb/ppc-linux-tdep.c	Tue Aug 12 09:22:11 2003
> @@ -1075,10 +1075,35 @@
>      }
>  }
>  
> +int ppc_linux_single_step_mode = 0;
> +void
> +ppc_linux_software_single_step (enum target_signal sig , int bp_p)
> +{
> +  if (ppc_linux_single_step_mode)
> +    {
> +      rs6000_software_single_step (sig, bp_p);
> +    }
> +  else
> +    {
> +      internal_error (__FILE__, __LINE__, "Will never execute!");
> +    }
> +}
> +
>  void
>  _initialize_ppc_linux_tdep (void)
>  {
>    gdbarch_register_osabi (bfd_arch_powerpc, 0, GDB_OSABI_LINUX,
>  			  ppc_linux_init_abi);
>    add_core_fns (&ppc_linux_regset_core_fns);
> +
> +  add_show_from_set (add_set_cmd("single-step-mode", class_obscure,
> +				 var_integer,
> +				 &ppc_linux_single_step_mode, "\
> +Set single step mode for PowerPCtarget:\n\
> +  0 = Target supports single stepping (i.e. Linux)\n\
> +  1 = Target does not support single stepping (i.e. AIX, Simulators).",
> +				 &setlist),
> +		     &showlist);
>  }
> +
> +

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:

 KB> On Aug 12,  6:31pm, Jimi Xenidis wrote:
 KB> The patch looks mostly okay to me.  I do have some comments and questions
 KB> though...

 KB> 1) It is customary to provide ChangeLog entries with patch
 KB>    submissions.
Hows this?

2003-08-19  Jimi Xenidis  <jimix@watson.ibm.com>

	* ppc-linux-tdep.c (ppc_linux_software_single_step): Allow for
	single step mode (SW or HW assisted) to be selectable.
	* config/powerpc/tm-linux.h (SOFTWARE_SINGLE_STEP): Likewise

 KB> 2) Why is ``ppc_linux_single_step_mode'' an extern in tm-linux.h?  I
 KB>    would really prefer that it be local to ppc-linux-tdep.c.  If
 KB>    there's some compelling reason for it to not be local, then we can
 KB>    discuss adding it to ppc-tdep.h.
Both macros (one for test and one for that call itself) are used all
over the gdb source so I do not see how iether one can be local

 KB> 3) Is a copyright assignment needed for this patch?

 KB>    [ This question is not just for Jimi, but for others reading this
 KB>    list as well.  I'm leaving Jimi's patch quoted below so that others
 KB>    can look without having to dig up the original patch submission.  ]

I submitted this patch in hopes that it would sneak under the
copyright radar. Let me know if it does not

-JX

Re: Powerpc and software single step

[Daniel Jacobowitz]

On Tue, Aug 19, 2003 at 10:55:13AM -0700, Kevin Buettner wrote:
> On Aug 12,  6:31pm, Jimi Xenidis wrote:
> 
> > The AIX kernel does not support single step but the Linux kernel does.
> > 
> > However, I am working with a remote machine level debugger for PowerPC
> > that allows me to debug a running Linux kernel and cannot support
> > single stepping.  For this I require that when debugging a Linux
> > target I need to turn on SOFTWARE_SINGLE_STEP.
> >  
> > I would like to add this to an "obscure" setting that will turn it on
> > even under Linux.
> > Here is the patch.. please accept, feel free to mangle the symbol
> > names to taste.
> 
> The patch looks mostly okay to me.  I do have some comments and questions
> though...
> 
> 1) It is customary to provide ChangeLog entries with patch submissions.
> 
> 2) Why is ``ppc_linux_single_step_mode'' an extern in tm-linux.h?  I
>    would really prefer that it be local to ppc-linux-tdep.c.  If
>    there's some compelling reason for it to not be local, then we can
>    discuss adding it to ppc-tdep.h.

Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
in two non-platform-specific files: infptrace.c for a sanity check, and
infrun.c.  In infrun, the only line which matters for this case is in
resume:
    if (SOFTWARE_SINGLE_STEP_P () && step)

Why not add a hook to check there which lets the user use software
single step?  It'll require playing with the target macros; we'd need
something like:
  SOFTWARE_SINGLE_STEP - perform software single step
  SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
  SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
    (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)

I've wanted to flip back and forth at runtime before.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:

 DJ> On Tue, Aug 19, 2003 at 10:55:13AM -0700, Kevin Buettner wrote:

 >> 2) Why is ``ppc_linux_single_step_mode'' an extern in tm-linux.h?  I
 >> would really prefer that it be local to ppc-linux-tdep.c.  If
 >> there's some compelling reason for it to not be local, then we can
 >> discuss adding it to ppc-tdep.h.

 DJ> Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
 DJ> in two non-platform-specific files: infptrace.c for a sanity
 DJ> check,
This sanity check is wierd, does it expect PT_STEP to be defined _and_
not supported?

 DJ> Why not add a hook to check there which lets the user use software
 DJ> single step?  It'll require playing with the target macros; we'd need
 DJ> something like:
 DJ>   SOFTWARE_SINGLE_STEP - perform software single step
 DJ>   SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
 DJ>   SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
 DJ>     (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)

I believe that this increases the complexity of the solution.
On first inspection it looks like the proper solution is simply
abstracting single step and let the code do the appropriate
thing.. but that could easily break older targets that are not
actively maintained, but I yield to senior heads on this.

My first attempt was to drag ppc/rs6000 into the gdbarch world and
drop the #defines all together.  However, the test (_P) rotuine tests
a function pointer and it was not readily apparent how to have a set
command set a function pointer or actually run code to do so. Perhaps
pairing it with a gdbarch boolean?

-JX

BTW: since generating the patch I have discovered that the
add_set_cmd() should actually be using var_boolean.

Re: Powerpc and software single step

[Daniel Jacobowitz]

On Tue, Aug 19, 2003 at 06:32:31PM -0400, Jimi Xenidis wrote:
> >>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  DJ> On Tue, Aug 19, 2003 at 10:55:13AM -0700, Kevin Buettner wrote:
> 
>  >> 2) Why is ``ppc_linux_single_step_mode'' an extern in tm-linux.h?  I
>  >> would really prefer that it be local to ppc-linux-tdep.c.  If
>  >> there's some compelling reason for it to not be local, then we can
>  >> discuss adding it to ppc-tdep.h.
> 
>  DJ> Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
>  DJ> in two non-platform-specific files: infptrace.c for a sanity
>  DJ> check,
> This sanity check is wierd, does it expect PT_STEP to be defined _and_
> not supported?

It does happen.  MIPS/Linux does that sometimes, so does anything else
where PT_STEP is restricted or broken.

>  DJ> Why not add a hook to check there which lets the user use software
>  DJ> single step?  It'll require playing with the target macros; we'd need
>  DJ> something like:
>  DJ>   SOFTWARE_SINGLE_STEP - perform software single step
>  DJ>   SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
>  DJ>   SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
>  DJ>     (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)
> 
> I believe that this increases the complexity of the solution.
> On first inspection it looks like the proper solution is simply
> abstracting single step and let the code do the appropriate
> thing.. but that could easily break older targets that are not
> actively maintained, but I yield to senior heads on this.
> 
> My first attempt was to drag ppc/rs6000 into the gdbarch world and
> drop the #defines all together.  However, the test (_P) rotuine tests
> a function pointer and it was not readily apparent how to have a set
> command set a function pointer or actually run code to do so. Perhaps
> pairing it with a gdbarch boolean?

I'm not sure what you mean.  I actually left out something from my
example; above would be macros set by the architecture, and there would
be a USE_SOFTWARE_SINGLE_STEP_P that would be user controlled but
default based the architecture.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:

 DJ> On Tue, Aug 19, 2003 at 06:32:31PM -0400, Jimi Xenidis wrote:
 >> This sanity check is wierd, does it expect PT_STEP to be defined _and_
 >> not supported?

 DJ> It does happen.  MIPS/Linux does that sometimes, so does anything else
 DJ> where PT_STEP is restricted or broken.

heh, go figure.

 >> My first attempt was to drag ppc/rs6000 into the gdbarch world and
 >> drop the #defines all together.  However, the test (_P) rotuine tests
 >> a function pointer and it was not readily apparent how to have a set
 >> command set a function pointer or actually run code to do so. Perhaps
 >> pairing it with a gdbarch boolean?

 DJ> I'm not sure what you mean.
To quickly re-cap, I wanted to be able to switch the single step mode
dynamically by creating a "set" command.  Unfortunately:

int
gdbarch_software_single_step_p (struct gdbarch *gdbarch)
{
  gdb_assert (gdbarch != NULL);
  return gdbarch->software_single_step != NULL;
}

I do not see a way to assign this function pointer off of the set
command, unless there is a some trick I did not see.
maybe we could fix this with more code, but sadly I'm limited in my
ability to push out patches under the current circumstances.

But all of these solutions are not the real one which probably takes
more commitment then available (at least from me at the moment ;-)

-JX

Re: Powerpc and software single step

[Daniel Jacobowitz]

On Tue, Aug 19, 2003 at 10:57:29PM -0400, Jimi Xenidis wrote:
> >>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  DJ> On Tue, Aug 19, 2003 at 06:32:31PM -0400, Jimi Xenidis wrote:
>  >> This sanity check is wierd, does it expect PT_STEP to be defined _and_
>  >> not supported?
> 
>  DJ> It does happen.  MIPS/Linux does that sometimes, so does anything else
>  DJ> where PT_STEP is restricted or broken.
> 
> heh, go figure.
> 
>  >> My first attempt was to drag ppc/rs6000 into the gdbarch world and
>  >> drop the #defines all together.  However, the test (_P) rotuine tests
>  >> a function pointer and it was not readily apparent how to have a set
>  >> command set a function pointer or actually run code to do so. Perhaps
>  >> pairing it with a gdbarch boolean?
> 
>  DJ> I'm not sure what you mean.
> To quickly re-cap, I wanted to be able to switch the single step mode
> dynamically by creating a "set" command.  Unfortunately:
> 
> int
> gdbarch_software_single_step_p (struct gdbarch *gdbarch)
> {
>   gdb_assert (gdbarch != NULL);
>   return gdbarch->software_single_step != NULL;
> }
> 
> I do not see a way to assign this function pointer off of the set
> command, unless there is a some trick I did not see.
> maybe we could fix this with more code, but sadly I'm limited in my
> ability to push out patches under the current circumstances.
> 
> But all of these solutions are not the real one which probably takes
> more commitment then available (at least from me at the moment ;-)

set_gdbarch_software_single_step?  You couldn't do it
architecture-independently, perhaps.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:

 DJ> On Tue, Aug 19, 2003 at 10:57:29PM -0400, Jimi Xenidis wrote:

 DJ> set_gdbarch_software_single_step?  You couldn't do it
 DJ> architecture-independently, perhaps.

I could not figure out how to trigger, from user space, a call to this
function toggeling between some known function pointer and NULL.
Did I miss it or perhaps another command (not "set") would suffice?
-JX

Re: Powerpc and software single step

[Daniel Jacobowitz]

On Tue, Aug 19, 2003 at 11:21:28PM -0400, Jimi Xenidis wrote:
> >>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  DJ> On Tue, Aug 19, 2003 at 10:57:29PM -0400, Jimi Xenidis wrote:
> 
>  DJ> set_gdbarch_software_single_step?  You couldn't do it
>  DJ> architecture-independently, perhaps.
> 
> I could not figure out how to trigger, from user space, a call to this
> function toggeling between some known function pointer and NULL.
> Did I miss it or perhaps another command (not "set") would suffice?

If you write a set command that has an associated sfunc, the sfunc can
call whatever you wish. Take a look at the end of cp-abi.c.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:

 DJ> On Tue, Aug 19, 2003 at 11:21:28PM -0400, Jimi Xenidis wrote:

 DJ> If you write a set command that has an associated sfunc, the sfunc can
 DJ> call whatever you wish. Take a look at the end of cp-abi.c.

Ahhh this is exactly what I was looking for.. thank you
-JX

Re: Powerpc and software single step

[Andrew Cagney]

> I do not see a way to assign this function pointer off of the set
>> command, unless there is a some trick I did not see.
>> maybe we could fix this with more code, but sadly I'm limited in my
>> ability to push out patches under the current circumstances.
>> 
>> But all of these solutions are not the real one which probably takes
>> more commitment then available (at least from me at the moment ;-)
> 
> 
> set_gdbarch_software_single_step?  You couldn't do it
> architecture-independently, perhaps.

That would be wrong.  An architecture vector should not change 
underneath GDB's feet.

It may be possible to wrap software single step's predicate in a 
function that, like the remote protocol, returns the predicate, or 
always false.

Andrew

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:

 AC> That would be wrong.  An architecture vector should not change 
 AC> underneath GDB's feet.

 AC> It may be possible to wrap software single step's predicate in a 
 AC> function that, like the remote protocol, returns the predicate, or 
 AC> always false.

It is my understanding that the predicate is use to conditionally wrap
the "vector" is it usefull for the predicate to be anything more then
a boolean in gdbarch?

-JX

Re: Powerpc and software single step

[Andrew Cagney]

> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>  AC> That would be wrong.  An architecture vector should not change 
>  AC> underneath GDB's feet.
> 
>  AC> It may be possible to wrap software single step's predicate in a 
>  AC> function that, like the remote protocol, returns the predicate, or 
>  AC> always false.
> 
> It is my understanding that the predicate is use to conditionally wrap
> the "vector" is it usefull for the predicate to be anything more then
> a boolean in gdbarch?

Sorry, I don't understand your question.

Andrew

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:

 AC> It may be possible to wrap software single step's predicate in a 
 AC> function that, like the remote protocol, returns the predicate, or 
 AC> always false.
 >> 
 >> It is my understanding that the predicate is use to conditionally wrap
 >> the "vector" is it usefull for the predicate to be anything more then
 >> a boolean in gdbarch?

 AC> Sorry, I don't understand your question.

Ok, its probably my lingo shortcommings.
the ppc trees still use the olf MACROS:
  SOFTWARE_SINGLE_STEP_P (the predicate?)
  SOFTWARE_SINGLE_STEP   (the function which is the gdbarch "vector")

since the eval of the predicate is checked before the function is
called I opted to toy with the predicate in is macro form to decide
its value.  Unfortunately in gdbarch land the predicate
simply tests for the vector being !=NULL.

So my quiestion is really about introducing a boolean to gdbarch that
can changed by some user action (such as set).  But if it is the "test
then call" itself that you are objecting to then obviously this will
not solve that.

-JX

Re: Powerpc and software single step

[Andrew Cagney]

>>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>  AC> It may be possible to wrap software single step's predicate in a 
>  AC> function that, like the remote protocol, returns the predicate, or 
>  AC> always false.
>  >> 
>  >> It is my understanding that the predicate is use to conditionally wrap
>  >> the "vector" is it usefull for the predicate to be anything more then
>  >> a boolean in gdbarch?
> 
>  AC> Sorry, I don't understand your question.
> 
> Ok, its probably my lingo shortcommings.
> the ppc trees still use the olf MACROS:
>   SOFTWARE_SINGLE_STEP_P (the predicate?)
>   SOFTWARE_SINGLE_STEP   (the function which is the gdbarch "vector")

What about a patch to eliminate the macros?  Good incremental step.

> since the eval of the predicate is checked before the function is
> called I opted to toy with the predicate in is macro form to decide
> its value.  Unfortunately in gdbarch land the predicate
> simply tests for the vector being !=NULL.
> 
> So my quiestion is really about introducing a boolean to gdbarch that
> can changed by some user action (such as set).  But if it is the "test
> then call" itself that you are objecting to then obviously this will
> not solve that.

Once created, the architecture object doesn't change - it's describing 
the architecture and not the UI state.

There are a number of factors that determine if software single step 
should be used:

- architecture supports/implemented it
- target doesn't support hardware single step (to be done)
- user requested that software/hardware stepping be used (your addition)

I suspect that both Daniel and I are (each in a round about way) 
suggesting that the code be modified to use a function containing all 
those tests.

Andrew

Re: Powerpc and software single step

[Jimi Xenidis]

>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:

 >> Ok, its probably my lingo shortcommings.
 >> the ppc trees still use the olf MACROS:
 >> SOFTWARE_SINGLE_STEP_P (the predicate?)
 >> SOFTWARE_SINGLE_STEP   (the function which is the gdbarch "vector")

 AC> What about a patch to eliminate the macros?  Good incremental step.

Agreed, but because the predicate tests the vector != NULL it is a
step away from the feature I need, which is to change the evaluation
of the preditcate at runtime.

 AC> Once created, the architecture object doesn't change - it's describing 
 AC> the architecture and not the UI state.

Ok, I see that now.  How about adding a predicate vector to gdbarch
being the "Good incremental step"?

 AC> I suspect that both Daniel and I are (each in a round about way) 
 AC> suggesting that the code be modified to use a function containing all 
 AC> those tests.

Are you describing the function predicate, or an all singing all
dancing single-step function (as I suggested as well).

-JX

Re: Powerpc and software single step

[Andrew Cagney]

>>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>  >> Ok, its probably my lingo shortcommings.
>  >> the ppc trees still use the olf MACROS:
>  >> SOFTWARE_SINGLE_STEP_P (the predicate?)
>  >> SOFTWARE_SINGLE_STEP   (the function which is the gdbarch "vector")
> 
>  AC> What about a patch to eliminate the macros?  Good incremental step.
> 
> Agreed, but because the predicate tests the vector != NULL it is a
> step away from the feature I need, which is to change the evaluation
> of the preditcate at runtime.

It is a big step towards what GDB needs though.

>  AC> Once created, the architecture object doesn't change - it's describing 
>  AC> the architecture and not the UI state.
> 
> Ok, I see that now.  How about adding a predicate vector to gdbarch
> being the "Good incremental step"?
> 
>  AC> I suspect that both Daniel and I are (each in a round about way) 
>  AC> suggesting that the code be modified to use a function containing all 
>  AC> those tests.
> 
> Are you describing the function predicate, or an all singing all
> dancing single-step function (as I suggested as well).

I guess I'm describing an all singing all dancing software single step 
predicate function.  There are several problems here:

- the decision to use / not-use s/w single step (architecture? target? user?
- the actual implementation of s/w single step

It would partially address the first problem.

Andrew

Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:

 AC> What about a patch to eliminate the macros?  Good incremental step.

Your wish is my (very much delayed) command ;-)

Changelog:

2003-09-08  Jimi Xenidis  <jimix@watson.ibm.com>

	* config/rs6000/tm-rs6000.h: no longer require custion #define of
	SOFTWARE_SINGLE_STEP
	* config/powerpc/tm-linux.h: no longer require custion #define of
	SOFTWARE_SINGLE_STEP
	* rs6000-tdep.c (rs6000_gdbarch_init): Set up software_single_step
	while initing gdbarch

Patch:
Index: gdb/rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.148
diff -u -u -r1.148 rs6000-tdep.c
--- gdb/rs6000-tdep.c	18 Aug 2003 20:04:55 -0000	1.148
+++ gdb/rs6000-tdep.c	8 Sep 2003 17:51:53 -0000
@@ -3015,6 +3015,9 @@
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
+  /* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
+  set_gdbarch_software_single_step (gdbarch, rs6000_software_single_step);
+
   return gdbarch;
 }
 
Index: gdb/config/powerpc/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/tm-linux.h,v
retrieving revision 1.14
diff -u -u -r1.14 tm-linux.h
--- gdb/config/powerpc/tm-linux.h	3 Sep 2003 21:01:44 -0000	1.14
+++ gdb/config/powerpc/tm-linux.h	8 Sep 2003 17:51:53 -0000
@@ -31,12 +31,6 @@
 #undef IN_SOLIB_CALL_TRAMPOLINE
 #undef SKIP_TRAMPOLINE_CODE
 
-/* We can single step on linux */
-#undef  SOFTWARE_SINGLE_STEP
-#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
-#undef  SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
-
 /* Make sure nexti gets the help it needs for debugging assembly code
    without symbols */
 
Index: gdb/config/rs6000/tm-rs6000.h
===================================================================
RCS file: /cvs/src/src/gdb/config/rs6000/tm-rs6000.h,v
retrieving revision 1.26
diff -u -u -r1.26 tm-rs6000.h
--- gdb/config/rs6000/tm-rs6000.h	3 Sep 2003 21:01:44 -0000	1.26
+++ gdb/config/rs6000/tm-rs6000.h	8 Sep 2003 17:51:53 -0000
@@ -90,12 +90,6 @@
 extern CORE_ADDR init_frame_pc_noop (int fromleaf, struct frame_info *prev);
 #define DEPRECATED_INIT_FRAME_PC(fromleaf, prev) (init_frame_pc_noop (fromleaf, prev))
 
-/* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
-
-#define SOFTWARE_SINGLE_STEP_P() 1
-extern void rs6000_software_single_step (enum target_signal, int);
-#define SOFTWARE_SINGLE_STEP(sig,bp_p) rs6000_software_single_step (sig, bp_p)
-
 /* Notice when a new child process is started. */
 
 #define TARGET_CREATE_INFERIOR_HOOK rs6000_create_inferior

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Daniel Jacobowitz]

On Mon, Sep 08, 2003 at 02:58:30PM -0400, Jimi Xenidis wrote:
> >>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
> 
>  AC> What about a patch to eliminate the macros?  Good incremental step.
> 
> Your wish is my (very much delayed) command ;-)
> 
> Changelog:
> 
> 2003-09-08  Jimi Xenidis  <jimix@watson.ibm.com>
> 
> 	* config/rs6000/tm-rs6000.h: no longer require custion #define of
> 	SOFTWARE_SINGLE_STEP
> 	* config/powerpc/tm-linux.h: no longer require custion #define of
> 	SOFTWARE_SINGLE_STEP
> 	* rs6000-tdep.c (rs6000_gdbarch_init): Set up software_single_step
> 	while initing gdbarch

Eh, no.  This patch would turn on software single-step for GNU/Linux
also - I doubt that's what you wanted to do.

> 
> Patch:
> Index: gdb/rs6000-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
> retrieving revision 1.148
> diff -u -u -r1.148 rs6000-tdep.c
> --- gdb/rs6000-tdep.c	18 Aug 2003 20:04:55 -0000	1.148
> +++ gdb/rs6000-tdep.c	8 Sep 2003 17:51:53 -0000
> @@ -3015,6 +3015,9 @@
>    /* Hook in ABI-specific overrides, if they have been registered.  */
>    gdbarch_init_osabi (info, gdbarch);
>  
> +  /* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
> +  set_gdbarch_software_single_step (gdbarch, rs6000_software_single_step);
> +
>    return gdbarch;
>  }
>  
> Index: gdb/config/powerpc/tm-linux.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/powerpc/tm-linux.h,v
> retrieving revision 1.14
> diff -u -u -r1.14 tm-linux.h
> --- gdb/config/powerpc/tm-linux.h	3 Sep 2003 21:01:44 -0000	1.14
> +++ gdb/config/powerpc/tm-linux.h	8 Sep 2003 17:51:53 -0000
> @@ -31,12 +31,6 @@
>  #undef IN_SOLIB_CALL_TRAMPOLINE
>  #undef SKIP_TRAMPOLINE_CODE
>  
> -/* We can single step on linux */
> -#undef  SOFTWARE_SINGLE_STEP
> -#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
> -#undef  SOFTWARE_SINGLE_STEP_P
> -#define SOFTWARE_SINGLE_STEP_P() 0
> -
>  /* Make sure nexti gets the help it needs for debugging assembly code
>     without symbols */
>  
> Index: gdb/config/rs6000/tm-rs6000.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/rs6000/tm-rs6000.h,v
> retrieving revision 1.26
> diff -u -u -r1.26 tm-rs6000.h
> --- gdb/config/rs6000/tm-rs6000.h	3 Sep 2003 21:01:44 -0000	1.26
> +++ gdb/config/rs6000/tm-rs6000.h	8 Sep 2003 17:51:53 -0000
> @@ -90,12 +90,6 @@
>  extern CORE_ADDR init_frame_pc_noop (int fromleaf, struct frame_info *prev);
>  #define DEPRECATED_INIT_FRAME_PC(fromleaf, prev) (init_frame_pc_noop (fromleaf, prev))
>  
> -/* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
> -
> -#define SOFTWARE_SINGLE_STEP_P() 1
> -extern void rs6000_software_single_step (enum target_signal, int);
> -#define SOFTWARE_SINGLE_STEP(sig,bp_p) rs6000_software_single_step (sig, bp_p)
> -
>  /* Notice when a new child process is started. */
>  
>  #define TARGET_CREATE_INFERIOR_HOOK rs6000_create_inferior
> 
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:

 DJ> On Mon, Sep 08, 2003 at 02:58:30PM -0400, Jimi Xenidis wrote:
 >> >>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
 >> 
 AC> What about a patch to eliminate the macros?  Good incremental step.
 >> 
 >> Your wish is my (very much delayed) command ;-)

 DJ> Eh, no.  This patch would turn on software single-step for GNU/Linux

This patch simply removes the macro definitions.  It does _not_ turn
on software single step for GNU/Linux since the macro tests for the
gdbarch vector which is NULL because it is undefined, but it is
defined for AIX.

I have verified this by both watching it with gdb and with strace
output.

 DJ>  also I doubt that's what you wanted to do.

You are right in that it is not what I wanted when this whole thing
started, but it was suggested that I remove the macro before I propose
the ability to select SW over HW at runtime.

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Daniel Jacobowitz]

On Mon, Sep 08, 2003 at 04:16:47PM -0400, Jimi Xenidis wrote:
> >>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  DJ> On Mon, Sep 08, 2003 at 02:58:30PM -0400, Jimi Xenidis wrote:
>  >> >>>>> "AC" == Andrew Cagney <ac131313@redhat.com> writes:
>  >> 
>  AC> What about a patch to eliminate the macros?  Good incremental step.
>  >> 
>  >> Your wish is my (very much delayed) command ;-)
> 
>  DJ> Eh, no.  This patch would turn on software single-step for GNU/Linux
> 
> This patch simply removes the macro definitions.  It does _not_ turn
> on software single step for GNU/Linux since the macro tests for the
> gdbarch vector which is NULL because it is undefined, but it is
> defined for AIX.
> 
> I have verified this by both watching it with gdb and with strace
> output.

Are you sure you posted the patch you tested?

You added a call to set_gdbarch_software_single_step to
rs6000_gdbarch_init.  It wasn't conditional on anything relating to
AIX.  By all rights that _should_ set gdbarch_software_singlestep_p for
GNU/Linux.


> 
>  DJ>  also I doubt that's what you wanted to do.
> 
> You are right in that it is not what I wanted when this whole thing
> started, but it was suggested that I remove the macro before I propose
> the ability to select SW over HW at runtime.
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
 DJ> Are you sure you posted the patch you tested?

yes and it was tested on aix.

 DJ> You added a call to set_gdbarch_software_single_step to
 DJ> rs6000_gdbarch_init.  It wasn't conditional on anything relating to
 DJ> AIX.  By all rights that _should_ set gdbarch_software_singlestep_p for
 DJ> GNU/Linux.

I agree with you and am equally puzzled, but it does not, I expected
to wrap it in:
  if (info->osabi != GDB_OSABI_LINUX)
but it was not necessary.
Actually wanted == GDB_OSABI_AIX but there was no such animal.

thoughts?

-JX

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Kevin Buettner]

On Sep 8,  5:22pm, Jimi Xenidis wrote:

> >>>>> "DJ" == Daniel Jacobowitz <drow@mvista.com> writes:
>  DJ> Are you sure you posted the patch you tested?
> 
> yes and it was tested on aix.
> 
>  DJ> You added a call to set_gdbarch_software_single_step to
>  DJ> rs6000_gdbarch_init.  It wasn't conditional on anything relating to
>  DJ> AIX.  By all rights that _should_ set gdbarch_software_singlestep_p for
>  DJ> GNU/Linux.
> 
> I agree with you and am equally puzzled, but it does not, I expected
> to wrap it in:
>   if (info->osabi != GDB_OSABI_LINUX)
> but it was not necessary.
> Actually wanted == GDB_OSABI_AIX but there was no such animal.
> 
> thoughts?

Would you mind doing some tracing to figure out why wrapping it
with a test for AIX wasn't necessary?  The fact that you didn't
need a test suggests that there's a bug somewhere else...

Kevin

Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:

 KB> On Sep 8,  5:22pm, Jimi Xenidis wrote:
 >> 
 >> I agree with you and am equally puzzled, but it does not, I expected
 >> to wrap it in:
 >> if (info->osabi != GDB_OSABI_LINUX)
 >> but it was not necessary.
 >> Actually wanted == GDB_OSABI_AIX but there was no such animal.

 KB> Would you mind doing some tracing to figure out why wrapping it
 KB> with a test for AIX wasn't necessary?  The fact that you didn't
 KB> need a test suggests that there's a bug somewhere else...

sure.
-JX

AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:

 KB> Would you mind doing some tracing to figure out why wrapping it
 KB> with a test for AIX wasn't necessary?  The fact that you didn't
 KB> need a test suggests that there's a bug somewhere else...

gdb/config/powerpc/tm-ppc-eabi.h defines the predicate
SOFTWARE_SINGLE_STEP_P() as 0 but does not define
SOFTWARE_SINGLE_STEP() at all. If I remove this def then all works as
expected.

So what should the AIX test be? possible canidates are:
  ? if (info.osabi != GDB_OSABI_LINUX)
    * Not sure if this is good enough for the PPC-EABI or anyone else
  ? if (from_xcoff_exec)

or clear it to NULL in ppclinux and eabi.

thoughts?
-JX

Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Kevin Buettner]

On Sep 9, 11:30am, Jimi Xenidis wrote:

> >>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:
> 
>  KB> Would you mind doing some tracing to figure out why wrapping it
>  KB> with a test for AIX wasn't necessary?  The fact that you didn't
>  KB> need a test suggests that there's a bug somewhere else...
> 
> gdb/config/powerpc/tm-ppc-eabi.h defines the predicate
> SOFTWARE_SINGLE_STEP_P() as 0 but does not define
> SOFTWARE_SINGLE_STEP() at all. If I remove this def then all works as
> expected.
> 
> So what should the AIX test be? possible canidates are:
>   ? if (info.osabi != GDB_OSABI_LINUX)
>     * Not sure if this is good enough for the PPC-EABI or anyone else
>   ? if (from_xcoff_exec)
> 
> or clear it to NULL in ppclinux and eabi.
> 
> thoughts?

Ideally, we'd have a GDB_OSABI_AIX constant to use for the test.

It'd also be nice if (eventually) the generic vs AIX specific code
were split into two separate files.  At first, I was thinking that AIX
specific code ought to move to a different file, but now I think it makes
more sense to do it the other way around, i.e, move the generic PPC
(and Power) code to its own file and let rs6000-tdep.c contain only
AIX specific code in much the same way that ppc-linux-tdep.c contains
only linux specific code.

Kevin

Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Jimi Xenidis]

>>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:

 KB> Ideally, we'd have a GDB_OSABI_AIX constant to use for the test.

ok, but I'll be using the if (from_xcoff_exec) early in the function
to assign info.osabi to it.
Is that acceptable for this patch, will submit if you agree.

 KB> It'd also be nice if (eventually) the generic vs AIX specific code
 KB> were split into two separate files.

This sounds perfect to me.. but can we do that "eventually" ;-)

-JX

Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP from ppc Was: Powerpc and software single step

[Kevin Buettner]

On Sep 9,  1:01pm, Jimi Xenidis wrote:

> >>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:
> 
>  KB> Ideally, we'd have a GDB_OSABI_AIX constant to use for the test.
> 
> ok, but I'll be using the if (from_xcoff_exec) early in the function
> to assign info.osabi to it.
> Is that acceptable for this patch, will submit if you agree.

I'd prefer to see GDB_OSABI_AIX set via a sniffer.  For the time
being, you can just use ``from_xcoff_exec'' for the test.  Please
add a comment which indicates that the test ought to be eventually
changed to use GDB_OSABI_AIX when it becomes available.  (Actually,
once things are properly split apart, the test goes away.)

Kevin

PATCH: Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP

[Jimi Xenidis]

>>>>> "KB" == Kevin Buettner <kevinb@redhat.com> writes:

 KB> For the time being, you can just use ``from_xcoff_exec'' for the
 KB> test.  Please add a comment which indicates that the test ought
 KB> to be eventually changed to use GDB_OSABI_AIX when it becomes
 KB> available.  (Actually, once things are properly split apart, the
 KB> test goes away.)

You wish is my command and thanks for the help.
-JX


diff -Naur -X Xdiff src/gdb/ChangeLog mygdb/gdb/ChangeLog
--- src/gdb/ChangeLog	Tue Sep  9 17:33:08 2003
+++ mygdb/gdb/ChangeLog	Tue Sep  9 17:03:52 2003
@@ -1,3 +1,14 @@
+2003-09-09  Jimi Xenidis  <jimix@watson.ibm.com>
+
+	* config/powerpc/tm-ppc-eabi.h:  no longer require custion #define of
+	SOFTWARE_SINGLE_STEP
+	* config/rs6000/tm-rs6000.h: no longer require custion #define of
+	SOFTWARE_SINGLE_STEP
+	* config/powerpc/tm-linux.h: no longer require custion #define of
+	SOFTWARE_SINGLE_STEP
+	* rs6000-tdep.c (rs6000_gdbarch_init): Set up software_single_step
+	while initing gdbarch
+
 2003-09-09  Ian Lance Taylor  <ian@wasabisystems.com>
 
 	* MAINTAINERS: Update my e-mail address.
diff -Naur -X Xdiff src/gdb/config/powerpc/tm-linux.h mygdb/gdb/config/powerpc/tm-linux.h
--- src/gdb/config/powerpc/tm-linux.h	Mon Sep  8 10:06:36 2003
+++ mygdb/gdb/config/powerpc/tm-linux.h	Mon Sep  8 10:03:28 2003
@@ -31,12 +31,6 @@
 #undef IN_SOLIB_CALL_TRAMPOLINE
 #undef SKIP_TRAMPOLINE_CODE
 
-/* We can single step on linux */
-#undef  SOFTWARE_SINGLE_STEP
-#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
-#undef  SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
-
 /* Make sure nexti gets the help it needs for debugging assembly code
    without symbols */
 
diff -Naur -X Xdiff src/gdb/config/powerpc/tm-ppc-eabi.h mygdb/gdb/config/powerpc/tm-ppc-eabi.h
--- src/gdb/config/powerpc/tm-ppc-eabi.h	Fri Apr 12 15:48:37 2002
+++ mygdb/gdb/config/powerpc/tm-ppc-eabi.h	Tue Sep  9 10:54:48 2003
@@ -24,9 +24,6 @@
 
 /* Use generic RS6000 definitions. */
 #include "rs6000/tm-rs6000.h"
-/* except we want to allow single stepping */
-#undef SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
 
 #undef PROCESS_LINENUMBER_HOOK
 
diff -Naur -X Xdiff src/gdb/config/rs6000/tm-rs6000.h mygdb/gdb/config/rs6000/tm-rs6000.h
--- src/gdb/config/rs6000/tm-rs6000.h	Mon Sep  8 10:06:36 2003
+++ mygdb/gdb/config/rs6000/tm-rs6000.h	Mon Sep  8 10:05:43 2003
@@ -90,12 +90,6 @@
 extern CORE_ADDR init_frame_pc_noop (int fromleaf, struct frame_info *prev);
 #define DEPRECATED_INIT_FRAME_PC(fromleaf, prev) (init_frame_pc_noop (fromleaf, prev))
 
-/* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
-
-#define SOFTWARE_SINGLE_STEP_P() 1
-extern void rs6000_software_single_step (enum target_signal, int);
-#define SOFTWARE_SINGLE_STEP(sig,bp_p) rs6000_software_single_step (sig, bp_p)
-
 /* Notice when a new child process is started. */
 
 #define TARGET_CREATE_INFERIOR_HOOK rs6000_create_inferior
diff -Naur -X Xdiff src/gdb/rs6000-tdep.c mygdb/gdb/rs6000-tdep.c
--- src/gdb/rs6000-tdep.c	Tue Sep  9 17:33:09 2003
+++ mygdb/gdb/rs6000-tdep.c	Tue Sep  9 17:08:02 2003
@@ -3013,6 +3013,16 @@
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
+  if (from_xcoff_exec)
+    {
+      /* Note: jimix/2003-06-09: This test should really check for
+	 GDB_OSABI_AIX then 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);
+    }
+
   return gdbarch;
 }
 

Re: PATCH: Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP

[Kevin Buettner]

On Sep 9,  6:01pm, Jimi Xenidis wrote:

> diff -Naur -X Xdiff src/gdb/ChangeLog mygdb/gdb/ChangeLog
> --- src/gdb/ChangeLog	Tue Sep  9 17:33:08 2003
> +++ mygdb/gdb/ChangeLog	Tue Sep  9 17:03:52 2003
> @@ -1,3 +1,14 @@
> +2003-09-09  Jimi Xenidis  <jimix@watson.ibm.com>
> +
> +	* config/powerpc/tm-ppc-eabi.h:  no longer require custion #define of
> +	SOFTWARE_SINGLE_STEP
> +	* config/rs6000/tm-rs6000.h: no longer require custion #define of
> +	SOFTWARE_SINGLE_STEP
> +	* config/powerpc/tm-linux.h: no longer require custion #define of
> +	SOFTWARE_SINGLE_STEP
> +	* rs6000-tdep.c (rs6000_gdbarch_init): Set up software_single_step
> +	while initing gdbarch

This is okay so long as the nits we discussed privately -- ChangeLog entry
formatting and comment wording -- are fixed.

Thanks,

Kevin

Re: PATCH: Re: AHAH! Re: Patch to eliminate SOFTWARE_SINGLE_STEP

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

> On Sep 9,  6:01pm, Jimi Xenidis wrote:
> 
> 
>> diff -Naur -X Xdiff src/gdb/ChangeLog mygdb/gdb/ChangeLog
>> --- src/gdb/ChangeLog	Tue Sep  9 17:33:08 2003
>> +++ mygdb/gdb/ChangeLog	Tue Sep  9 17:03:52 2003
>> @@ -1,3 +1,14 @@
>> +2003-09-09  Jimi Xenidis  <jimix@watson.ibm.com>
>> +
>> +	* config/powerpc/tm-ppc-eabi.h:  no longer require custion #define of
>> +	SOFTWARE_SINGLE_STEP
>> +	* config/rs6000/tm-rs6000.h: no longer require custion #define of
>> +	SOFTWARE_SINGLE_STEP
>> +	* config/powerpc/tm-linux.h: no longer require custion #define of
>> +	SOFTWARE_SINGLE_STEP
>> +	* rs6000-tdep.c (rs6000_gdbarch_init): Set up software_single_step
>> +	while initing gdbarch
> 
> 
> This is okay so long as the nits we discussed privately -- ChangeLog entry
> formatting and comment wording -- are fixed.

FYI, I've checked this in for Jimi.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3493 bytes --]

2003-10-09  Andrew Cagney  <cagney@redhat.com>

	Changes from 2003-09-09 Jimi Xenidis <jimix@watson.ibm.com>:
	* config/rs6000/tm-rs6000.h (SOFTWARE_SINGLE_STEP): Delete macro.
	(SOFTWARE_SINGLE_STEP_P): Ditto.
	* config/powerpc/tm-ppc-eabi.h (SOFTWARE_SINGLE_STEP_P): Ditto.
	* config/powerpc/tm-linux.h (SOFTWARE_SINGLE_STEP): Ditto.
	(SOFTWARE_SINGLE_STEP_P): Ditto.
	* rs6000-tdep.c (rs6000_gdbarch_init): When AIX, set
	software_single_step to rs6000_software_single_step.
	
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.166
diff -u -r1.166 rs6000-tdep.c
--- rs6000-tdep.c	3 Oct 2003 21:11:39 -0000	1.166
+++ rs6000-tdep.c	10 Oct 2003 02:35:14 -0000
@@ -3008,6 +3008,16 @@
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
+  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);
+    }
+
   return gdbarch;
 }
 
Index: config/powerpc/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/tm-linux.h,v
retrieving revision 1.14
diff -u -r1.14 tm-linux.h
--- config/powerpc/tm-linux.h	3 Sep 2003 21:01:44 -0000	1.14
+++ config/powerpc/tm-linux.h	10 Oct 2003 02:35:14 -0000
@@ -31,12 +31,6 @@
 #undef IN_SOLIB_CALL_TRAMPOLINE
 #undef SKIP_TRAMPOLINE_CODE
 
-/* We can single step on linux */
-#undef  SOFTWARE_SINGLE_STEP
-#define SOFTWARE_SINGLE_STEP(p,q) internal_error (__FILE__, __LINE__, "Will never execute!")
-#undef  SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
-
 /* Make sure nexti gets the help it needs for debugging assembly code
    without symbols */
 
Index: config/powerpc/tm-ppc-eabi.h
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/tm-ppc-eabi.h,v
retrieving revision 1.10
diff -u -r1.10 tm-ppc-eabi.h
--- config/powerpc/tm-ppc-eabi.h	12 Apr 2002 19:48:37 -0000	1.10
+++ config/powerpc/tm-ppc-eabi.h	10 Oct 2003 02:35:14 -0000
@@ -24,9 +24,6 @@
 
 /* Use generic RS6000 definitions. */
 #include "rs6000/tm-rs6000.h"
-/* except we want to allow single stepping */
-#undef SOFTWARE_SINGLE_STEP_P
-#define SOFTWARE_SINGLE_STEP_P() 0
 
 #undef PROCESS_LINENUMBER_HOOK
 
Index: config/rs6000/tm-rs6000.h
===================================================================
RCS file: /cvs/src/src/gdb/config/rs6000/tm-rs6000.h,v
retrieving revision 1.27
diff -u -r1.27 tm-rs6000.h
--- config/rs6000/tm-rs6000.h	22 Sep 2003 17:45:02 -0000	1.27
+++ config/rs6000/tm-rs6000.h	10 Oct 2003 02:35:14 -0000
@@ -84,12 +84,6 @@
   (fromleaf ? DEPRECATED_SAVED_PC_AFTER_CALL (prev->next) : \
 	      prev->next ? DEPRECATED_FRAME_SAVED_PC (prev->next) : read_pc ())
 
-/* RS6000/AIX does not support PT_STEP.  Has to be simulated.  */
-
-#define SOFTWARE_SINGLE_STEP_P() 1
-extern void rs6000_software_single_step (enum target_signal, int);
-#define SOFTWARE_SINGLE_STEP(sig,bp_p) rs6000_software_single_step (sig, bp_p)
-
 /* Notice when a new child process is started. */
 
 #define TARGET_CREATE_INFERIOR_HOOK rs6000_create_inferior

Re: Powerpc and software single step

[Andrew Cagney]

> Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
> in two non-platform-specific files: infptrace.c for a sanity check, and
> infrun.c.  In infrun, the only line which matters for this case is in
> resume:
>     if (SOFTWARE_SINGLE_STEP_P () && step)
> 
> Why not add a hook to check there which lets the user use software
> single step?  It'll require playing with the target macros; we'd need
> something like:
>   SOFTWARE_SINGLE_STEP - perform software single step
>   SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
>   SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
>     (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)
> 
> I've wanted to flip back and forth at runtime before.

See:  Cleanup software single step.
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=120
(but don't take the suggested solution literally).

I think kevin was playing with it (?) - search the mail archives.  This 
needs to be fixed - I don't think a workaround is acceptable.

Andrew

Re: Powerpc and software single step

[Daniel Jacobowitz]

On Tue, Aug 19, 2003 at 10:30:20PM -0400, Andrew Cagney wrote:
> 
> >Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
> >in two non-platform-specific files: infptrace.c for a sanity check, and
> >infrun.c.  In infrun, the only line which matters for this case is in
> >resume:
> >    if (SOFTWARE_SINGLE_STEP_P () && step)
> >
> >Why not add a hook to check there which lets the user use software
> >single step?  It'll require playing with the target macros; we'd need
> >something like:
> >  SOFTWARE_SINGLE_STEP - perform software single step
> >  SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
> >  SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
> >    (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)
> >
> >I've wanted to flip back and forth at runtime before.
> 
> See:  Cleanup software single step.
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=120
> (but don't take the suggested solution literally).
> 
> I think kevin was playing with it (?) - search the mail archives.  This 
> needs to be fixed - I don't think a workaround is acceptable.

I _think_ that's a different problem...

In any case it's definitely a real problem.  See the post I made a few
days ago about a thread debugging problem which causes single steps to
turn into continues.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Powerpc and software single step

[Andrew Cagney]

> On Tue, Aug 19, 2003 at 10:30:20PM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >Could we do this slightly differently?  SOFTWARE_SINGLE_STEP_P is used
>> >in two non-platform-specific files: infptrace.c for a sanity check, and
>> >infrun.c.  In infrun, the only line which matters for this case is in
>> >resume:
>> >    if (SOFTWARE_SINGLE_STEP_P () && step)
>> >
>> >Why not add a hook to check there which lets the user use software
>> >single step?  It'll require playing with the target macros; we'd need
>> >something like:
>> >  SOFTWARE_SINGLE_STEP - perform software single step
>> >  SOFTWARE_SINGLE_STEP_P - SOFTWARE_SINGLE_STEP available
>> >  SOFTWARE_SINGLE_STEP_ONLY_P - no hardware singlestep available
>> >    (check that in infptrace instead of SOFTWARE_SINGLE_STEP_P?)
>> >
>> >I've wanted to flip back and forth at runtime before.
> 
>> 
>> See:  Cleanup software single step.
>> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=120
>> (but don't take the suggested solution literally).
>> 
>> I think kevin was playing with it (?) - search the mail archives.  This 
>> needs to be fixed - I don't think a workaround is acceptable.
> 
> 
> I _think_ that's a different problem...

It's all part of a `software single step is sideways / backwards 
problem'.  Missing from the PR are the gdbarch.sh comments (and 
references to earlier discussion):

# FIXME/cagney/2001-01-18: This should be split in two.  A target method 
that indicates if
# the target needs software single step.  An ISA method to implement it.
#
# FIXME/cagney/2001-01-18: This should be replaced with something that 
inserts breakpoints
# using the breakpoint system instead of blatting memory directly (as 
with rs6000).
#
# FIXME/cagney/2001-01-18: The logic is backwards.  It should be asking 
if the target can
# single step.  If not, then implement single step using breakpoints.

"infrun.c" should make its decision based on:

- user selectable single step (yes, no, auto -> auto boolean variable) 
(new to this thread)
- target selectable single step
- architecture implement's software single step (which needs a new 
mechanism)

Adding a user command would side step the middle part - target vector 
addition to indicate that the target supports software single step - but 
would at least provide a workaround.

> In any case it's definitely a real problem.  See the post I made a few
> days ago about a thread debugging problem which causes single steps to
> turn into continues.

Andrew