[RFA] set/show enable-software-singlestep

[RFA] set/show enable-software-singlestep

[Michael Snyder]

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

There may be cases where gdb would be inclined to use
software singlestep, but you might not want it to.  Examples:

 * "target remote" to a target such as a simulator that
   would be able to support normal singlestep.

 * reverse debugging, where you can't predict the 
   "come-from" address of a jump instruction.

What do you guys think?  Useful?



[-- Attachment #2: swss.txt --]
[-- Type: text/plain, Size: 1937 bytes --]

2008-06-23  Michael Snyder  <msnyder@localhost.localdomain>

	* gdbarch.c (enable_sw_ss): New mode variable.
	(show_enable_sw_ss): New setshow helper function.
	(gdbarch_software_single_step_p): If enable_sw_ss is false, 
	just return zero.
	(_initialize_gdbarch): Add setshow command for
	enable-software-singlestep (default true).

Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.428
diff -u -p -r1.428 gdbarch.c
--- gdbarch.c	24 May 2008 16:32:01 -0000	1.428
+++ gdbarch.c	24 Jun 2008 18:15:30 -0000
@@ -2486,11 +2486,26 @@ set_gdbarch_smash_text_address (struct g
   gdbarch->smash_text_address = smash_text_address;
 }
 
+int enable_sw_ss = 1;
+
+static void
+show_enable_sw_ss (struct ui_file *file, int from_tty,
+		   struct cmd_list_element *c,
+		   const char *value)
+{
+  fprintf_filtered (file, _("\
+Debugger's willingness to use software singlestep is %s.\n"),
+		    value);
+}
+
 int
 gdbarch_software_single_step_p (struct gdbarch *gdbarch)
 {
   gdb_assert (gdbarch != NULL);
-  return gdbarch->software_single_step != NULL;
+  if (enable_sw_ss)
+    return gdbarch->software_single_step != NULL;
+  else
+    return 0;
 }
 
 int
@@ -3635,4 +3650,13 @@ When non-zero, architecture debugging is
                             NULL,
                             show_gdbarch_debug,
                             &setdebuglist, &showdebuglist);
+  add_setshow_zinteger_cmd ("enable-software-singlestep", class_support, 
+			    &enable_sw_ss, _("\
+Set debugger's willingness to use software singlestep."), _("\
+Show debugger's willingness to use software singlestep."), _("\
+If zero, gdb will not use software singlestep, even if\n\
+the architecture API would seem to call for it."),
+                            NULL,
+                            show_enable_sw_ss,
+                            &setlist, &showlist);
 }

Re: [RFA] set/show enable-software-singlestep

[Daniel Jacobowitz]

On Tue, Jun 24, 2008 at 11:18:54AM -0700, Michael Snyder wrote:
> 2008-06-23  Michael Snyder  <msnyder@localhost.localdomain>
> 
> 	* gdbarch.c (enable_sw_ss): New mode variable.

This is a generated file... I recommend you leave the meaning of
gdbarch_software_single_step_p alone, and do the adjustment at its caller.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] set/show enable-software-singlestep

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Tue, 24 Jun 2008 11:18:54 -0700
> 
>  * "target remote" to a target such as a simulator that
>    would be able to support normal singlestep.
> 
>  * reverse debugging, where you can't predict the 
>    "come-from" address of a jump instruction.
> 
> What do you guys think?  Useful?

It would be, if it were documented in the manual ;-)

Thanks.

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

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

On Tue, 2008-06-24 at 14:29 -0400, Daniel Jacobowitz wrote:
> On Tue, Jun 24, 2008 at 11:18:54AM -0700, Michael Snyder wrote:
> > 2008-06-23  Michael Snyder  <msnyder@localhost.localdomain>
> > 
> > 	* gdbarch.c (enable_sw_ss): New mode variable.
> 
> This is a generated file...

D'oh!  Oh yeah...


> I recommend you leave the meaning of
> gdbarch_software_single_step_p alone, and do the adjustment at its caller.

Good suggestion.  How about the attached?

On Tue, 2008-06-24 at 21:42 +0300, Eli Zaretskii wrote: 
> It would be, if it were documented in the manual ;-)

I hear thee, O voice crying out in the wilderness.
I was just gonna... wait until we'd hashed out the user interface!
Yeah, that's my story...   ;-)



[-- Attachment #2: canuse.txt --]
[-- Type: text/plain, Size: 2529 bytes --]

2008-06-23  Michael Snyder  <msnyder@specifix.com>

	* infrun.c (can_use_sw_ss): New mode variable.
	(show_can_use_sw_ss): New setshow helper function.
	(resume): Check for can-use-software-singlestep.
	(_initialize_infrun): Add set/show command for 
	can-use-software-singlestep.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.281
diff -u -p -r1.281 infrun.c
--- infrun.c	13 Jun 2008 20:19:19 -0000	1.281
+++ infrun.c	24 Jun 2008 19:22:49 -0000
@@ -583,6 +583,21 @@ static CORE_ADDR displaced_step_original
 /* Saved contents of copy area.  */
 static gdb_byte *displaced_step_saved_copy;
 
+/* When this is non-zero (default), we are allowed to use software
+   singlestep, if the architecture supports it.  When zero, we will
+   use the normal singlestep model even if the architecture/abi would
+   not normally permit it.  */
+int can_use_sw_ss = 1;
+static void
+show_can_use_sw_ss (struct ui_file *file, int from_tty,
+		    struct cmd_list_element *c,
+		    const char *value)
+{
+  fprintf_filtered (file, _("\
+Debugger's willingness to use software singlestep is %s.\n"),
+		    value);
+}
+
 /* When this is non-zero, we are allowed to use displaced stepping, if
    the architecture supports it.  When this is zero, we use
    traditional the hold-and-step approach.  */
@@ -947,9 +962,9 @@ a command like `return' or `jump' to con
 	return;
     }
 
-  if (step && gdbarch_software_single_step_p (gdbarch))
+  if (step && can_use_sw_ss && gdbarch_software_single_step_p (gdbarch))
     {
-      /* Do it the hard way, w/temp breakpoints */
+      /* Do it the hard way, w/temp breakpoints ("software singlestep").  */
       if (gdbarch_software_single_step (gdbarch, get_current_frame ()))
         {
           /* ...and don't ask hardware to do it.  */
@@ -4634,6 +4649,16 @@ breakpoints, even if such is supported b
 			    &maintenance_set_cmdlist,
 			   &maintenance_show_cmdlist);
 
+  add_setshow_boolean_cmd ("can-use-software-singlestep", class_maintenance, 
+			   &can_use_sw_ss, _("\
+Set debugger's willingness to use software singlestep."), _("\
+Show debugger's willingness to use software singlestep."), _("\
+If zero, gdb will not use software singlestep, even if\n\
+the architecture API would seem to call for it."),
+			   NULL,
+			   show_can_use_sw_ss,
+			   &maintenance_set_cmdlist,
+			   &maintenance_show_cmdlist);
 
   /* ptid initializations */
   null_ptid = ptid_build (0, 0, 0);

Re: [RFA] set/show enable-software-singlestep

[Luis Machado]

On Tue, 2008-06-24 at 11:18 -0700, Michael Snyder wrote:
> There may be cases where gdb would be inclined to use
> software singlestep, but you might not want it to.  Examples:
> 
>  * "target remote" to a target such as a simulator that
>    would be able to support normal singlestep.
> 
>  * reverse debugging, where you can't predict the 
>    "come-from" address of a jump instruction.
> 
> What do you guys think?  Useful?

It's a useful feature and looks OK. I'm just wondering how dangerous it
would be to turn software single stepping off on PPC64 and stumble upon
an atomic sequence and end up locked there (we use software single
stepping explicitly to jump those sequences).

Regards,
Luis

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

On Tue, 2008-06-24 at 16:29 -0300, Luis Machado wrote:
> On Tue, 2008-06-24 at 11:18 -0700, Michael Snyder wrote:
> > There may be cases where gdb would be inclined to use
> > software singlestep, but you might not want it to.  Examples:
> > 
> >  * "target remote" to a target such as a simulator that
> >    would be able to support normal singlestep.
> > 
> >  * reverse debugging, where you can't predict the 
> >    "come-from" address of a jump instruction.
> > 
> > What do you guys think?  Useful?
> 
> It's a useful feature and looks OK. I'm just wondering how dangerous it
> would be to turn software single stepping off on PPC64 and stumble upon
> an atomic sequence and end up locked there (we use software single
> stepping explicitly to jump those sequences).

Well, it would be dangerous (ie. fatal) any time when software
singlestep is actually required.  It's only meant for when you
know it isn't required, even though normally it would be.

In my revised patch, I've made it a "maintainer" command.
Later if we decide that users can be trusted with it, we
can promote it.   ;-)

Re: [RFA] set/show enable-software-singlestep

[Pedro Alves]

A Tuesday 24 June 2008 19:18:54, Michael Snyder wrote:
> There may be cases where gdb would be inclined to use
> software singlestep, but you might not want it to.  Examples:

I understand you want this for reverse debugging, so let me ask:

>  * "target remote" to a target such as a simulator that
>    would be able to support normal singlestep.

Should the support be reported by the stub instead?, as in:

Can the target (stub/debug api) do single-stepping?  Yes, cool.
No?  Bummer, will have to do software-singlestepping
on the GDB's side.

E.g, another similar issue with displaced stepping:
(hey you just touched that option :-) )

I'm working with a target that supports stepping 
off breakpoints on the stub side.  I was thinking of:

  Can the target (stub/debug api) step over breakpoints for me?
  Yes, cool.  No?  Bummer, will have to do displaced-stepping
  on the GDB's side.

>  * reverse debugging, where you can't predict the
>    "come-from" address of a jump instruction.

Should software-singlestepping *always* be disabled
while doing a reverse debug?  If so, why do we need the
command?  Shouldn't it be enforced in the code?

-- 
Pedro Alves

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

On Tue, 2008-06-24 at 21:07 +0100, Pedro Alves wrote:
> A Tuesday 24 June 2008 19:18:54, Michael Snyder wrote:
> > There may be cases where gdb would be inclined to use
> > software singlestep, but you might not want it to.  Examples:
> 
> I understand you want this for reverse debugging, so let me ask:
> 
> >  * "target remote" to a target such as a simulator that
> >    would be able to support normal singlestep.
> 
> Should the support be reported by the stub instead?, as in:
> 
> Can the target (stub/debug api) do single-stepping?  Yes, cool.
> No?  Bummer, will have to do software-singlestepping
> on the GDB's side.

Yes, that would certainly be cool -- automate the choice.
At the moment, I don't know of any stub that can report
that capability, so I'd like to be able to do it explicitly.


> E.g, another similar issue with displaced stepping:
> (hey you just touched that option :-) )

Yes, I was noticing that!  Sounds like a cool capability.

> I'm working with a target that supports stepping 
> off breakpoints on the stub side.  I was thinking of:
> 
>   Can the target (stub/debug api) step over breakpoints for me?
>   Yes, cool.  No?  Bummer, will have to do displaced-stepping
>   on the GDB's side.
> 
> >  * reverse debugging, where you can't predict the
> >    "come-from" address of a jump instruction.
> 
> Should software-singlestepping *always* be disabled
> while doing a reverse debug?  If so, why do we need the
> command?  Shouldn't it be enforced in the code?

Possibly.  I haven't gotten that far along in my thinking.
Just seemed like a reasonable starting point was to be
able to set it by hand.

And as I said, there might be other cases where you'd
like to do this other than reverse debugging.

Re: [RFA] set/show enable-software-singlestep

[Joel Brobecker]

Hi Michael,

> 2008-06-23  Michael Snyder  <msnyder@specifix.com>
> 
> 	* infrun.c (can_use_sw_ss): New mode variable.
> 	(show_can_use_sw_ss): New setshow helper function.
> 	(resume): Check for can-use-software-singlestep.
> 	(_initialize_infrun): Add set/show command for 
> 	can-use-software-singlestep.

As discussed previously on gdb@, I think this is a useful feature
even outside of reverse debugging.  Regarding Pedro's question
about making this feature transparent, that would be tough for
the example I gave, which is Tru64 - we want to be able to use
s/w single-step only on programs that use threads. To make it automatic,
we'd have to reliably detect that a program uses threads. Perhaps
this is doable, but having the option is an easy first step. Later
on, we can always extend the option to a tri-state with an "auto"
setting if it helps...

The code itself looks good, but I'm not so sure about accessing this
feature through a "maint" command. Since in my eyes it's a feature,
I'd personally be inclined to make it accessible through  "set/show
can-use-software-singlestep".  It is an obscure feature, however, so
I'm not really that concerned about it. How about we wait for another
week to see if we have any other comment; if not, then just commit
as is.

-- 
Joel

Re: [RFA] set/show enable-software-singlestep

[Daniel Jacobowitz]

On Wed, Jun 25, 2008 at 08:54:24AM -0400, Joel Brobecker wrote:
> Hi Michael,
> 
> > 2008-06-23  Michael Snyder  <msnyder@specifix.com>
> > 
> > 	* infrun.c (can_use_sw_ss): New mode variable.
> > 	(show_can_use_sw_ss): New setshow helper function.
> > 	(resume): Check for can-use-software-singlestep.
> > 	(_initialize_infrun): Add set/show command for 
> > 	can-use-software-singlestep.
> 
> As discussed previously on gdb@, I think this is a useful feature
> even outside of reverse debugging.  Regarding Pedro's question
> about making this feature transparent, that would be tough for
> the example I gave, which is Tru64 - we want to be able to use
> s/w single-step only on programs that use threads. To make it automatic,
> we'd have to reliably detect that a program uses threads. Perhaps
> this is doable, but having the option is an easy first step. Later
> on, we can always extend the option to a tri-state with an "auto"
> setting if it helps...

I think it should already be auto.  can-use-software-singlestep is
unintuitive - either do use it, don't use it, or use GDB's best
judgement.  And if the user selects to use it and it isn't supported,
that's an error when we next want to singlestep.  WDYT?

> The code itself looks good, but I'm not so sure about accessing this
> feature through a "maint" command. Since in my eyes it's a feature,
> I'd personally be inclined to make it accessible through  "set/show
> can-use-software-singlestep".  It is an obscure feature, however, so
> I'm not really that concerned about it. How about we wait for another
> week to see if we have any other comment; if not, then just commit
> as is.

I agree with Joel; if we want to have the user knob at all, no gain in
hiding it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] set/show enable-software-singlestep

[Joel Brobecker]

> I think it should already be auto.  can-use-software-singlestep is
> unintuitive - either do use it, don't use it, or use GDB's best
> judgement.  And if the user selects to use it and it isn't supported,
> that's an error when we next want to singlestep.  WDYT?

That sounds like a good idea to me, I agree that the feature is
a little obscure for someone who's not familiar with the GDB code...

-- 
Joel

Re: [RFA] set/show enable-software-singlestep

[Pedro Alves]

A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
>
> I think it should already be auto.  can-use-software-singlestep is
> unintuitive - either do use it, don't use it, or use GDB's best
> judgement.  And if the user selects to use it and it isn't supported,
> that's an error when we next want to singlestep.  WDYT?

Well, not really auto.  If a ARM stub does software singlestepping itself
(say we add it to gdbserver), gdb will still do software
single-stepping (breakpoint dance), wont it?

> I agree with Joel; if we want to have the user knob at all, no gain in
> hiding it.

To be clear, I'm not against the knob, FWIW.

-- 
Pedro Alves

Re: [RFA] set/show enable-software-singlestep

[Pedro Alves]

A Wednesday 25 June 2008 13:54:24, Joel Brobecker wrote:

> As discussed previously on gdb@, I think this is a useful feature
> even outside of reverse debugging.  Regarding Pedro's question
> about making this feature transparent, that would be tough for
> the example I gave, which is Tru64 - we want to be able to use
> s/w single-step only on programs that use threads. To make it automatic,
> we'd have to reliably detect that a program uses threads. Perhaps
> this is doable, but having the option is an easy first step. Later
> on, we can always extend the option to a tri-state with an "auto"
> setting if it helps...

I'm just curious about it,

I can't figure which targets are used in Tru64.  Is it ptrace based?
From your description of not being able to hw singlestep
threaded programs, I take it threads are user space?

I'm thinking what we want is the other way around.  Can the
target singlestep itself?  Software-singlestepping with breakpoints
is the current fallback mechanism.

Is there a thread_stratum target used to implement the
thread support?

If so, we may be able to add a target_can_singlestep
{ yes/no } property/method and have the thread target return
false, with the default implementation returning "false".

 - yes - the target takes care of singlestepping.
    for archs that don't have hw singlestep support, but the
    target (stub or kernel) handles it.  That's what a Tru64
    target should report.

 - no - even though the the kernel or stub (the debug API, that is)
   support single stepping, GDB should fake singlestepping if the
   arch doesn't support hw singlestepping.  (usually by using 
   software-singlestepping breakpoints but emulating   
   instructions is another possibility, possible, e.g., we
   don't have to care about simulating exceptions.)  This is the
   default, and corresponds to what we have currently).

Just a quick thought dump.  I'm not against the new knob.

-- 
Pedro Alves

Re: [RFA] set/show enable-software-singlestep

[Joel Brobecker]

> I'm just curious about it,

Sure :).

> I can't figure which targets are used in Tru64.  Is it ptrace based?

Actually, I think it's procfs.

> From your description of not being able to hw singlestep
> threaded programs, I take it threads are user space?

Yes (DEC threads).

> I'm thinking what we want is the other way around.  Can the target
> singlestep itself?  Software-singlestepping with breakpoints is the
> current fallback mechanism.

Ideally, yes. We would like the debugger to automatically detect
whether software single-step is needed or not. The user-setting
is interesting for the cases when this detection is not implemented.
However, I won't argue that the change is so interesting that the
user setting must be checked in now so that we have early access
to it. I'm equally content to NOT have a user setting and let GDB
continue to use s/w single-step by default on Tru64.

> Is there a thread_stratum target used to implement the thread support?

Right now, no. As it turns out, however, it just happens that I
implemented this thread layer for dec-threads a two or three weeks ago.
It's ready to be submitted, but I did the work as quickly as possible
(for internal reasons) and so it seems to work, but I sometimes I have
this uneasy feeling that it's too simplistic.  So I want to give it
a little bit more testing, to see if I can avoid embarrassing myself
with silly code :). Not that it would be the first time, really...

-- 
Joel

Re: [RFA] set/show enable-software-singlestep

[Daniel Jacobowitz]

On Wed, Jun 25, 2008 at 03:14:38PM +0100, Pedro Alves wrote:
> A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
> >
> > I think it should already be auto.  can-use-software-singlestep is
> > unintuitive - either do use it, don't use it, or use GDB's best
> > judgement.  And if the user selects to use it and it isn't supported,
> > that's an error when we next want to singlestep.  WDYT?
> 
> Well, not really auto.  If a ARM stub does software singlestepping itself
> (say we add it to gdbserver), gdb will still do software
> single-stepping (breakpoint dance), wont it?

What Joel said elsewhere in the thread just now.  If we get a stub
that reports definitively that it can single step, that should take
priority over GDB knowing that software singlestep is implemented for
this architecture.

Um, uh-oh.  This will break the overloading of software single step
for bypassing atomic operations.  Clearly more thought is required!

Another unfortunate note: we can't trust the vCont reply for this even
though it's clearly the right thing :-(  Since current versions of GDB
reject replies without s/S.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] set/show enable-software-singlestep

[Pedro Alves]

A Wednesday 25 June 2008 15:42:15, Daniel Jacobowitz escreveu:
> On Wed, Jun 25, 2008 at 03:14:38PM +0100, Pedro Alves wrote:
> > A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
> > > I think it should already be auto.  can-use-software-singlestep is
> > > unintuitive - either do use it, don't use it, or use GDB's best
> > > judgement.  And if the user selects to use it and it isn't supported,
> > > that's an error when we next want to singlestep.  WDYT?
> >
> > Well, not really auto.  If a ARM stub does software singlestepping itself
> > (say we add it to gdbserver), gdb will still do software
> > single-stepping (breakpoint dance), wont it?
>
> What Joel said elsewhere in the thread just now.  If we get a stub
> that reports definitively that it can single step, that should take
> priority over GDB knowing that software singlestep is implemented for
> this architecture.
>

What I said elsewhere in the thread just now.  :-)  The stub should
report it, and a new target method is required, that takes precedence
for stepping operations.

> Um, uh-oh.  This will break the overloading of software single step
> for bypassing atomic operations.  Clearly more thought is required!
>

The stub should just either step it all atomically, and GDB sees
only one SIGTRAP, or we force continuing over the sequence with a
single-step breakpoint (as we do today), not telling the
stub to step at all (as we don't do today...).  We seems we need
to distinguish this in the reporting mechanism.  Another issue is
that the atomic operations bypassing is implemented inside
the software_singlestepping gdbarch methods.  It should be
factored out.

> Another unfortunate note: we can't trust the vCont reply for this even
> though it's clearly the right thing :-(  Since current versions of GDB
> reject replies without s/S.

Yep, I noticed that.  We'll need something else, probably
qSupported (if we're thinking of supporting multi arch
stubs, care must be taken here as well).

-- 
Pedro Alves

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

Silence equals assent?

On Mon, 2008-06-30 at 14:43 -0700, Michael Snyder wrote:
> Any convergence on this?
> 
> On Wed, 2008-06-25 at 16:03 +0100, Pedro Alves wrote:
> > A Wednesday 25 June 2008 15:42:15, Daniel Jacobowitz escreveu:
> > > On Wed, Jun 25, 2008 at 03:14:38PM +0100, Pedro Alves wrote:
> > > > A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
> > > > > I think it should already be auto.  can-use-software-singlestep is
> > > > > unintuitive - either do use it, don't use it, or use GDB's best
> > > > > judgement.  And if the user selects to use it and it isn't supported,
> > > > > that's an error when we next want to singlestep.  WDYT?
> > > >
> > > > Well, not really auto.  If a ARM stub does software singlestepping itself
> > > > (say we add it to gdbserver), gdb will still do software
> > > > single-stepping (breakpoint dance), wont it?
> > >
> > > What Joel said elsewhere in the thread just now.  If we get a stub
> > > that reports definitively that it can single step, that should take
> > > priority over GDB knowing that software singlestep is implemented for
> > > this architecture.
> > >
> > 
> > What I said elsewhere in the thread just now.  :-)  The stub should
> > report it, and a new target method is required, that takes precedence
> > for stepping operations.
> > 
> > > Um, uh-oh.  This will break the overloading of software single step
> > > for bypassing atomic operations.  Clearly more thought is required!
> > >
> > 
> > The stub should just either step it all atomically, and GDB sees
> > only one SIGTRAP, or we force continuing over the sequence with a
> > single-step breakpoint (as we do today), not telling the
> > stub to step at all (as we don't do today...).  We seems we need
> > to distinguish this in the reporting mechanism.  Another issue is
> > that the atomic operations bypassing is implemented inside
> > the software_singlestepping gdbarch methods.  It should be
> > factored out.
> > 
> > > Another unfortunate note: we can't trust the vCont reply for this even
> > > though it's clearly the right thing :-(  Since current versions of GDB
> > > reject replies without s/S.
> > 
> > Yep, I noticed that.  We'll need something else, probably
> > qSupported (if we're thinking of supporting multi arch
> > stubs, care must be taken here as well).
> > 
> 

Re: [RFA] set/show enable-software-singlestep

[Pedro Alves]

Hi Michael,

Sorry for the silence,

On Thursday 10 July 2008 03:46:10, Michael Snyder wrote:
> Silence equals assent?

I had understood the consensus was that the command would be
useful for now.

It would be really nice if someone that had a target that
always required disabling software-singlestepping stepped forward
to add the GDB/remote smarts to do it automatically, though.  ;-)

>
> On Mon, 2008-06-30 at 14:43 -0700, Michael Snyder wrote:
> > Any convergence on this?
> >
> > On Wed, 2008-06-25 at 16:03 +0100, Pedro Alves wrote:
> > > A Wednesday 25 June 2008 15:42:15, Daniel Jacobowitz escreveu:
> > > > On Wed, Jun 25, 2008 at 03:14:38PM +0100, Pedro Alves wrote:
> > > > > A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
> > > > > > I think it should already be auto.  can-use-software-singlestep
> > > > > > is unintuitive - either do use it, don't use it, or use GDB's
> > > > > > best judgement.  And if the user selects to use it and it isn't
> > > > > > supported, that's an error when we next want to singlestep. 
> > > > > > WDYT?
> > > > >
> > > > > Well, not really auto.  If a ARM stub does software singlestepping
> > > > > itself (say we add it to gdbserver), gdb will still do software
> > > > > single-stepping (breakpoint dance), wont it?
> > > >
> > > > What Joel said elsewhere in the thread just now.  If we get a stub
> > > > that reports definitively that it can single step, that should take
> > > > priority over GDB knowing that software singlestep is implemented for
> > > > this architecture.
> > >
> > > What I said elsewhere in the thread just now.  :-)  The stub should
> > > report it, and a new target method is required, that takes precedence
> > > for stepping operations.
> > >
> > > > Um, uh-oh.  This will break the overloading of software single step
> > > > for bypassing atomic operations.  Clearly more thought is required!
> > >
> > > The stub should just either step it all atomically, and GDB sees
> > > only one SIGTRAP, or we force continuing over the sequence with a
> > > single-step breakpoint (as we do today), not telling the
> > > stub to step at all (as we don't do today...).  We seems we need
> > > to distinguish this in the reporting mechanism.  Another issue is
> > > that the atomic operations bypassing is implemented inside
> > > the software_singlestepping gdbarch methods.  It should be
> > > factored out.
> > >
> > > > Another unfortunate note: we can't trust the vCont reply for this
> > > > even though it's clearly the right thing :-(  Since current versions
> > > > of GDB reject replies without s/S.
> > >
> > > Yep, I noticed that.  We'll need something else, probably
> > > qSupported (if we're thinking of supporting multi arch
> > > stubs, care must be taken here as well).



-- 
Pedro Alves

Re: [RFA] set/show enable-software-singlestep

[Daniel Jacobowitz]

On Thu, Jul 10, 2008 at 12:07:19PM +0100, Pedro Alves wrote:
> I had understood the consensus was that the command would be
> useful for now.
> 
> It would be really nice if someone that had a target that
> always required disabling software-singlestepping stepped forward
> to add the GDB/remote smarts to do it automatically, though.  ;-)

I'd like to have some conclusion on how normal software single step
and special software single step interact.  Are all the things handled
in GDB's software single step routine also the responsibility of any
stub that claims single step support?

Which is not how it works today - we let a powerpc gdbserver single
step most things, but detect atomic sequences in the client.  This
avoids duplicating the logic across all stubs, but is slower.

And do these special stepping types get turned off if you disable
software single stepping manually?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

On Thu, 2008-07-10 at 12:07 +0100, Pedro Alves wrote:
> Hi Michael,
> 
> Sorry for the silence,
> 
> On Thursday 10 July 2008 03:46:10, Michael Snyder wrote:
> > Silence equals assent?
> 
> I had understood the consensus was that the command would be
> useful for now.
> 
> It would be really nice if someone that had a target that
> always required disabling software-singlestepping stepped forward
> to add the GDB/remote smarts to do it automatically, though.  ;-)

Tell you what -- if you will suggest a syntax for the transaction,
I will try adding it to my gdb-freeplay target.

That'll provide a 'use case' for its being useful.   ;-)

Re: [RFA] set/show enable-software-singlestep

[Michael Snyder]

On Thu, 2008-07-10 at 18:47 -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 10, 2008 at 12:07:19PM +0100, Pedro Alves wrote:
> > I had understood the consensus was that the command would be
> > useful for now.
> > 
> > It would be really nice if someone that had a target that
> > always required disabling software-singlestepping stepped forward
> > to add the GDB/remote smarts to do it automatically, though.  ;-)
> 
> I'd like to have some conclusion on how normal software single step
> and special software single step interact.  Are all the things handled
> in GDB's software single step routine also the responsibility of any
> stub that claims single step support?
> 
> Which is not how it works today - we let a powerpc gdbserver single
> step most things, but detect atomic sequences in the client.  This
> avoids duplicating the logic across all stubs, but is slower.
> 
> And do these special stepping types get turned off if you disable
> software single stepping manually?

Well, it seems to me that "normal single-step" is the base
case, and "software single-step" is the special case.

By telling gdb *not* to use software single-step, we're
just telling it to revert to the "base" behavior, whatever
that might be.

It doesn't seem to me that the non-software-singlestep
should then be obliged to emulate everything that might
have been done by the special-case software singlestep.