Re: remote debugging a multi-threaded program with signal

Daniel Jacobowitz
2004-03-06T17:11:14Z

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