This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: remote debugging a multi-threaded program with signal


On Sat, Mar 06, 2004 at 01:43:43AM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> 
> anemo> How about when verbose-resume was disabled or unavailable?  If
> anemo> verbose-resume is necessary to continue with signal, gdb can
> anemo> warn it for users?  Or gdbserver can resume all threads on this
> anemo> case?
> 
> 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'.
> 
> --- gdb-6.0.90.org/gdb/gdbserver/target.c	Wed Jun 12 02:32:40 2002
> +++ gdb-6.0.90/gdb/gdbserver/target.c	Sat Mar  6 01:29:44 2004
> @@ -49,6 +49,10 @@ set_desired_inferior (int use_general)
>        if (found == NULL)
>  	found = (struct thread_info *) find_inferior_id (&all_threads,
>  							 cont_thread);
> +      /* failsafe: use thread in last resume_reply */
> +      if (found == NULL)
> +	found = (struct thread_info *) find_inferior_id (&all_threads,
> +							 general_thread);
>      }
>  
>    if (found == NULL)

For one thing, I'm not sure it will work.  But for another, why is this
case important to you?

Without vCont the problem is fundamentally insoluble; there will always
be a case in which gdbserver mis-guesses which thread it should
continue.  That's why I had to come up with a protocol change.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]