Re: Q: multiple inferiors, all-stop && vCont

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 03 Aug 2010 18:53:59 +0200, Oleg Nesterov wrote:
> On 08/03, Jan Kratochvil wrote:
> > On Tue, 03 Aug 2010 16:30:04 +0200, Oleg Nesterov wrote:
> > > However, I do not really understand how this can work reliably in the
> > > terms of remote protocol. Somehow this scheme relies on the fact that
> > > gdb will send another vCont;t:pTGID.-1 _once again_ after the previous
> > > vCont;t:pTGID.-1, and gdbserver can report the other threads via
> > > Stop/vStopped. OK, I hope this doesn't matter.
> >
> > attach_command_post_wait:
> >
> >       /* At least the current thread is already stopped.  */
> >
> >       /* In all-stop, by definition, all threads have to be already
> >          stopped at this point.  In non-stop, however, although the
> >          selected thread is stopped, others may still be executing.
> >          Be sure to explicitly stop all threads of the process.  This
> >          should have no effect on already stopped threads.  */
> >       if (non_stop)
> >         target_stop (pid_to_ptid (inferior->pid));
> 
> This just reflects the current situation with the current implementation.
> gdb already did
> 
> 	vAttach;PID
> 	vCont;t:pPID.-1
> 
> I do not see anything in the _documentation_ which could explain that
> only the main thread can be stopped despite the fact "-1" means all
> threads.

"-1" really means all threads - all those gdbserver knows about that time.

Anyway this double-stop issue is gdbserver/libthread_db specific and offtopic
for ugdb.


> Once again, I already understand why gdb + gdbserver work this way,
> I meant remote protocol "in general".

In remote protocol - and even internally in gdbserve - "-1" really always
means all the (currently known) threads.


> And in fact, I do not think your explanation is correct. Yes, this
> attach_command_post_wait() is called during attach. But even after that
> gdbserver reports only the main thread. This happens before qSymbol
> stage.

This attach_command_post_wait code is executed after the qSymbol command.

The first single-thread vCont:

#0  putpkt (buf=0x1f348b0 "vCont;t:p517.-1") at remote.c:6730
#1  in remote_stop_ns (ptid=...) at remote.c:4709
#2  in remote_stop (ptid=...) at remote.c:4747
#3  in target_stop (ptid=...) at target.c:3031
#4  in attach_command (args=0x7fffffffd861 "1303", from_tty=1) at infcmd.c:2436
#5  in do_cfunc (c=0x1db8bf0, args=0x7fffffffd861 "1303", from_tty=1) at ./cli/cli-decode.c:67
#6  in cmd_func (cmd=0x1db8bf0, args=0x7fffffffd861 "1303", from_tty=1) at ./cli/cli-decode.c:1771
#7  in execute_command (p=0x7fffffffd864 "3", from_tty=1) at top.c:422
#8  in catch_command_errors (command=0x48a3e3 <execute_command>, arg=0x7fffffffd85a "attach 1303", from_tty=1, mask=6) at exceptions.c:534
#9  in captured_main (data=0x7fffffffd360) at ./main.c:887

The second all-threads vCont:

#0  putpkt (buf=0x1f4ecb0 "vCont;t:p517.-1") at remote.c:6730
#1  in remote_stop_ns (ptid=...) at remote.c:4709
#2  in remote_stop (ptid=...) at remote.c:4747
#3  in target_stop (ptid=...) at target.c:3031
#4  in attach_command_post_wait (args=0x1f3b6f0 "1303", from_tty=1, async_exec=0) at infcmd.c:2334
#5  in attach_command_continuation (args=0x1f3b6a0) at infcmd.c:2355
#6  in do_my_cleanups (pmy_chain=0x7fffffffcd08, old_chain=0x0) at utils.c:421
#7  in do_all_inferior_continuations () at utils.c:692
#8  in inferior_event_handler (event_type=INF_EXEC_COMPLETE, client_data=0x0) at inf-loop.c:96
#9  in fetch_inferior_event (client_data=0x0) at infrun.c:2649
#10 in fetch_inferior_event_wrapper (client_data=0x0) at inf-loop.c:169
#11 in catch_errors (func=0x6b4287 <fetch_inferior_event_wrapper>, func_args=0x0, errstring=0xe378dd "", mask=6) at exceptions.c:518
#12 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at inf-loop.c:65
#13 in remote_async_serial_handler (scb=0x1f30b00, context=0x0) at remote.c:10317
#14 in push_event (context=0x1f30b00) at ser-base.c:176
#15 in handle_timer_event (dummy=...) at event-loop.c:1306
#16 in process_event () at event-loop.c:399
#17 in gdb_do_one_event (data=0x0) at event-loop.c:452
#18 in catch_errors (func=0x6b0d2a <gdb_do_one_event>, func_args=0x0, errstring=0xe07943 "", mask=6) at exceptions.c:518
#19 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:171
#20 in current_interp_command_loop () at interps.c:291
#21 in captured_command_loop (data=0x0) at ./main.c:227
#22 in catch_errors (func=0x47ff66 <captured_command_loop>, func_args=0x0, errstring=0xdc6967 "", mask=6) at exceptions.c:518
#23 in captured_main (data=0x7fffffffd360) at ./main.c:910


> But, it is very possible I missed something. Ang again, I think (I hope ;)
> we can forget this because the simple method works too.

This discussion is really offtopic for ugdb.


> I was afraid there are some other reason why we can't avoid libthread_db.

Roland has correctly pointed out the TLS support.  But that will come later.


> Yes, I do understand vAttach issues, but I thought that "attach"
> command should always hide these details. From the documentation:
> 
> 	attach PROCESS-ID
> 
> 		...
> 		The first thing GDB does after arranging to debug the specified
> 		process is to stop it.  You can examine and modify an attached process
> 		with all the GDB commands that are ordinarily available when you start
> 		processes with `run'.  You can insert breakpoints; you can step and
> 		continue; you can modify storage.  If you would rather the process
> 		continue running, you may use the `continue' command after attaching
> 		GDB to the process.

It is true "attach" stops the inferior.  Just the stop completes only after
the "attach" command returns.


Regards,
Jan