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, _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
