Re: vCont [was Re: Multithreaded debugging: strange thread switches]

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 24, 2006 at 06:34:38PM -0500, Nathan J. Williams wrote:
> 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?

Yeah, I've been meaning to fix that.  A better thing would be to modify
GDB to accept a vCont packet that only indicated continue, and then
issue an error if remote_resume tries to step.

-- 
Daniel Jacobowitz
CodeSourcery