This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
vCont [was Re: Multithreaded debugging: strange thread switches]
Daniel Jacobowitz <drow@false.org> writes:
> This, generally, is part of the problem. If you want this to work, you
> need to implement the vCont packet in the stub. The Hc1 packet is
> supposed to mean "step only thread 1, leaving thread 2 stopped", and
> that's not what the gdb "next" command is supposed to map to - that's
> "step this thread but leave other threads free-running".
Tangentially... I'm working on a stub for a system that doesn't have
hardware single-step; GDB knows that and doesn't try to issue any step
commands. However, the logic in remote.c that analyzes the response to
the vCont? packet refuses to use vCont unless it supports all of s, S,
c, and C. Is the best thing for my stub just to lie about supporting s
and S, and to rely on the knowledge that GDB won't try to use them?
- Nathan