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

[Pedro Alves <pedro_alves@portugalmail.pt>]

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