Re: remote debugging a multi-threaded program with signal

[Daniel Jacobowitz <drow@false.org>]

On Sat, Mar 06, 2004 at 09:50:01PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 5 Mar 2004 11:38:54 -0500, Daniel Jacobowitz <drow@false.org> said:
> 
> >> For gdb without verbose-resume, how about this patch?  With this
> >> patch, gdbserver uses general_thread instead of all_threads.head if
> >> 'CNN' packet was sent without preceding 'HcNN'.
> 
> drow> For one thing, I'm not sure it will work.  But for another, why
> drow> is this case important to you?
> 
> It solves at least my program case, and I believe it breaks nothing.
> 
> I'm still sometimes using (slightly patched) gdb 5.3.  If I can solve
> the problem with verbose-resume disabled in current gdb, I suppose the
> fixes can be backported to gdb 5.3 easily.  I already tried your fix of
> infrun.c with gdb 5.3 and found it solves a part of problem.
> 
> drow> Without vCont the problem is fundamentally insoluble; there will
> drow> always be a case in which gdbserver mis-guesses which thread it
> drow> should continue.  That's why I had to come up with a protocol
> drow> change.
> 
> Hmm... then it might be better to backport all vCont stuff?  Of course
> upgrading to upcoming gdb 6.1 will be the best solution, but I can not
> for now by some internal reason ... :-\

Yes, I would rather you backport vCont than we add hacks to gdbserver
to guess :)  I can tell you that the only changes to support vCont (as
far as I remember, anyway) were in remote.c.  It was pretty simple
client-side.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer