Re: [RFC] Cannot notify GDB when a new thread is created

On April 27, 2015 3:33:35 AM GMT+02:00, Sheng Yong <[email protected]> wrote:
>Hi, folks,
>
>When we testing GDB on uClibc, we find that some GDB testcases cannot
>pass.
>
>Here is one of them, no-unwaited-for-left.c, could be fount here,
>https://github.com/wallento/binutils-gdb/blob/master/gdb/testsuite/gdb.threads/no-unwaited-for-left.c
>
>This testcase tests the GDB feature called scheduler-locking, which
>could
>allow only the current traced pthread to run, while other pthreads
>stop.
>
>At the second breakpoint (line 65), if we try to stop the new pthread,
>or
>switch to the new pthread, it fails.
>
>===================== test case 1 ======================
>-bash-4.2# ./gdb no-unwaited-for-left
>... ...
>(gdb) b 65
>Breakpoint 1 at 0x88a8: file no-unwaited-for-left.c, line 65.
>(gdb) r
>Starting program: /tmp/no-unwaited-for-left
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/tmp/lib/libthread_db.so.1".
>
>Breakpoint 1, main () at no-unwaited-for-left.c:65
>65	no-unwaited-for-left.c: No such file or directory.
>(gdb) thread 2
>Thread ID 2 not known.
>(gdb) set scheduler-locking on
>(gdb) c
>Continuing.
>[Thread 0xb6ffb000 (LWP 27933) exited]
>No unwaited-for children left.
>Cannot remove breakpoints because program is no longer writable.
>Further execution is probably impossible.
>(gdb) i threads
>No threads.
>=======================================================
>
>However, if we `info threads' when breakpoint 2 reached, GDB behaves
>different.
>
>====================== test case 2 ====================
>-bash-4.2# ./gdb no-unwaited-for-left
>... ...
>(gdb) b 65
>Breakpoint 1 at 0x88a8: file no-unwaited-for-left.c, line 65.
>(gdb) r
>Starting program: /tmp/no-unwaited-for-left
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/tmp/lib/libthread_db.so.1".
>
>Breakpoint 1, main () at no-unwaited-for-left.c:65
>65	no-unwaited-for-left.c: No such file or directory.
>(gdb) i threads
>[New Thread 0xb6f5e4d0 (LWP 27945)]
>  Id   Target Id         Frame
>2    Thread 0xb6f5e4d0 (LWP 27945) "no-unwaited-for" 0xb6fe310c in
>pthread_join (threadid=3070210048, thread_return=0x0) at
>libpthread/nptl/pthread_join.c:88
>* 1    Thread 0xb6ffb000 (LWP 27941) "no-unwaited-for" main () at
>no-unwaited-for-left.c:65
>(gdb) set scheduler-locking on
>(gdb) c
>Continuing.
>[Thread 0xb6ffb000 (LWP 27941) exited]
>No unwaited-for children left.
>(gdb) i threads
>  Id   Target Id         Frame
>2    Thread 0xb6f5e4d0 (LWP 27945) "no-unwaited-for" 0xb6fe310c in
>pthread_join (threadid=3070210048, thread_return=0x0) at
>libpthread/nptl/pthread_join.c:88
>
>The current thread <Thread ID 1> has terminated.  See `help thread'.
>=======================================================
>
>This is because when new pthread is created, uClibc sometimes (?) does
>not
>generate a TD_CREATE event, which is caused by not setting
>__nptl_initial_report_events.
>As a result, the pthread info is not added to the thread_lists. But
>`info
>threads' could update thread_list.
>
>The patch from glibc (from Roland McGrath) `init.c
>(__nptl_initial_report_events): New
>variable.'
>(https://sourceware.org/git/?p=glibc.git;a=patch;f=nptl_db/td_thr_event_enable.c;h=7d9d8bd18906fdd17364f372b160d7ab896ce909)
>could solve the problem, but this context of the patch needs to be
>adjusted.
>
>Could this patch be added to uClibc?

Sure, please send a tested patch with appropriate s-o-b line.

TIA,