This is the mail archive of the mailing list for the Archer 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: Q: multiple inferiors, all-stop && vCont

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.


      /* 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));

> Yes. And please note that at least in-kernel gdbstub can not use
> libthread_db. But, I also hope that we can avoid it even if gdbstub
> runs in user-space ?

As far as I understand it now in-kernel gdbserver does not need libthread_db
at all.  The communication is based only on PID/TID anyway and on Linux we do
not need libthread_db to enumerate the TIDs of a PID.

> > Even FSF gdbserver does not seem to use/provide pthread_t identifiers:
> >   2 Thread 23487.23490  0x00007fb25c983a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
> > * 1 Thread 23487.23487  0x00007fb25cc63fbd in pthread_join (threadid=140404033701648, thread_return=0x0) at pthread_join.c:89
> >
> > as provided by local linux-nat.c / linux-thread-db.c.
> >   2 Thread 0x7ffff7842710 (LWP 23503)  0x00007ffff78e9a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
> > * 1 Thread 0x7ffff7ff3700 (LWP 23500)  0x00007ffff7bc9fbd in pthread_join (threadid=140737346021136, thread_return=0x0) at pthread_join.c:89
> >
> > The LWP -> thread_t conversion could be done later from the client side only
> > using:
> > libthread_db (td_ta_map_lwp2thr(), td_thr_get_info(),
> >               typeof (td_thrinfo_t->ti_tid) = thread_t)
> Cough. This is black magic to me ;)

This was more just a comment how to bring FSF gdbserver (or ugdb) on-par with
local linux-nat.c.  This is a future extension, so far I believe we should
more get udb on-par with FSF gdbserver.

FSF gdbserver itself already does not support displaying pthread_t IIUC.

> I probably understand what pthread_t is, but I do not know how/if this
> is important for gdb.

As all the pthread_* functions in inferior use pthread_t it is generally
useful to be able to associate pthread_t inferior values with the live threads
being debugged.

> Should I worry about this issue right now?

The pthread_t / libthread_db stuff should be probably only the GDB client
problem.  You will probably never face it.

> And, I hope that "client side only using: libthread_db" means gdb, not
> gdbserver ?

yes, I have meant it that way.

> > why do you want from GDB to use specifically `vCont:c'?
> Because, first of all, I wanted to understand why gdb doesn't send
> vCont:c to me, but uses this command when it works with the real
> gdbserver.

Anyway I see GDB uses `vCont;c' even with gdbstub so this problem is not
reproducible for me.

=> $vCont;c:p658.658
<= $OK

On Tue, 03 Aug 2010 17:06:56 +0200, Oleg Nesterov wrote:
> > > But probably gdb should be fixed anyway.
> >
> > There are so many serious bugs in GDB affecting regular GDB usage...
> OK, so I assume that the current behaviour of gdbstub is correct, even
> if stupid.

Yes, so far I do not see problems on the gdbstub side.

> > > Then send vCont:t ? "attach PID" means attach and stop it, no?
> >
> > But it is not yet stopped that time.
> Well. And how can I stop it?
> Once again, this all works in CLI mode. And this looks very natural

What do you call CLI mode?  We use only CLI mode so far all the time.  The
other mode is MI (`gdb -i=mi').

We can talk about local (=linux-nat.c, default without `target *remote') mode
or remote (=remote.c, `target extended-remote') mode.

With CLI remote mode with FSF gdbserver it also errors on:
	killall gdbserver gdbstub;~/redhat/threadit&p=$!;./gdbserver/gdbserver --remote-debug --multi :2000 &>~/redhat/out&sleep 0.1;./gdb -nx -ex 'set target-async on' -ex 'set non-stop' -ex "file $HOME/redhat/threadit" -ex 'target extended-remote :2000' -ex "attach $p" -ex 'set confirm no' -ex bt;kill $p; 
	Target is executing.

With CLI remote mode with gdbstub it also errors on:
	killall -9 gdbserver gdbstub;sleep 0.5;~/redhat/threadit&p=$!;~/redhat/gdbstub &>~/redhat/out&sleep 0.1;./gdb -nx -ex 'set target-async on' -ex 'set non-stop' -ex "file $HOME/redhat/threadit" -ex 'target extended-remote :2000' -ex "attach $p" -ex 'set confirm no' -ex bt;kill $p
	Target is executing.

With CLI local mode it prints a bogus backtrace:
	killall -9 gdbserver gdbstub;sleep 0.5;~/redhat/threadit&p=$!;sleep 0.1;./gdb -nx -ex 'set target-async on' -ex 'set non-stop' -ex "file $HOME/redhat/threadit" -ex "attach $p" -ex 'set confirm no' -ex bt;kill $p
	#0  0x00007fbc1989cfbd in ?? ()
	#1  0x00007fff7f643110 in ?? ()
	#2  0x00007fbc19ac5795 in ?? ()
	#3  0x00007fbc1989ce90 in ?? ()
	#4  0x00007fbc19515d38 in ?? ()
	#5  0x00007fbc177129e0 in ?? ()
	#6  0x0000000000000000 in ?? ()
	#0  0x00007fbc1989cfbd in pthread_join (threadid=140445855340304, thread_return=0x0) at pthread_join.c:89
	#1  0x000000000040074c in main () at threadit.c:30

> As a newbie user of gdb, I expected it is gdb who should take care
> and stop the tracee after "attach".

This was this way in the sync/all-stop mode.  In async/non-stop mode it is
intentionally asynchronous:

      if (target_can_async_p ())
          add_inferior_continuation (attach_command_continuation, a,

It may take some time before this inferior reports us back the stop and we may
want to debug other inferiors in the meantime.

> And please remember, "interrupt" doesn't help.

You need "wait-till-inferior-completes-interrupt" (which does not exist),
not "interrupt" which means "start-asynchronous-inferior-interruption".

> Yes, yes, now I understand this. Once again, I was greatly confused
> because I didn't know that CLI mode makes the difference. Even if I
                             ^^^ local (=non-remote) probably
> enter the commands via copy-and-paste, gdb always "completes" this
> attach before it reacts to "info registers".

It does not work before the target stops anyway in the local mode.  Trying to
access thread data while the thread is running can give stale data without
printing an error.  It is probably expected FE (Front End - such as Eclipse)
takes care of it anyway.

> > It is easy/normal in the GDB testsuite
> Hmm. How? probably the tests in testsuite wait for something which
> looks like "[Thread 5683.5683] #1 stopped." from gdb?

Yes, see gdb/testsuite/gdb.mi/mi-nonstop.exp for all its mi_expect_stop calls.
But that is the MI mode, not CLI mode, with commands like:
-break-insert -t main


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