This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] set/show enable-software-singlestep
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