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
