How to avoid stepping inside libpthread

[Atsushi Nemoto <anemo at mba dot ocn dot ne dot jp>]

When I keep typing "next" command in debug session, gdb might try to
do single stepping inside libpthread.  And on atomic operations (LL/SC
loop, as I'm using Linux/MIPS), the single stepping never ends.

GNU gdb 6.6
...
This GDB was configured as "mips-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b func		# thread's entry point
Breakpoint 1 at 0x400700: file foo.c, line 6.
(gdb) run
Starting program: ./foo
[Thread debugging using libthread_db enabled]
[New Thread 715939536 (LWP 756)]
[New Thread 726549712 (LWP 759)]
[Switching to Thread 726549712 (LWP 759)]

Breakpoint 1, func (arg=0x0) at foo.c:6 
6               return arg;		/* last statement of the thread */
(gdb) n
7       }
(gdb) 
0x2ab0ae88 in start_thread () from /lib/libpthread.so.0
(gdb) 
Single stepping until exit from function start_thread, 
which has no line number information.

The gdb stops.  

There is a LL/SC loop (atomic_decrement_and_test(&__nptl_nthreads))
after the 0x2ab0ae88 in start_thread(), so it is not wonder the single
stepping never ends (SC always fail due to a breakpoint exception).


Are there any way to avoid falling into such situations?  Only I can
do is be careful to not enter "next" command inside libpthread?


Once I fell into this situation, C-c can might stop the gdb, but
sometimes it cause internal-error.

../../gdb-6.6/gdb/linux-nat.c:1333: internal-error: wait_lwp: Assertion `lp->status == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

I have not investigated this error further.


And current gdb snapshot (6.6.50.20070711) behaves differently.

GNU gdb 6.6.50.20070711
...
This GDB was configured as "mips-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b func
Breakpoint 1 at 0x400700: file foo.c, line 6.
(gdb) run
Starting program: ./foo
warning: Can not parse XML target description; XML support was disabled at compile time
[New LWP 754]
[Switching to LWP 754]

Breakpoint 1, func (arg=0x0) at foo.c:6
6               return arg;		/* last statement of the thread */
(gdb) 
7       }
(gdb) 
warning: GDB can't find the start of the function at 0x2ab0ae88.

    GDB is unable to find the start of the function at 0x2ab0ae88
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2ab0ae88 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
warning: GDB can't find the start of the function at 0x2ab0ae87.
0x2ab0ae88 in ?? ()
(gdb) n
Cannot find bounds of current function


It seems current gdb snapshot can not find symbol for 0x2ab0ae88.  Is
this behavior intentional?

---
Atsushi Nemoto

#include <stdio.h>
#include <pthread.h>

void *func(void *arg)
{
	return arg;
}

int main(int argc, char **argv) 
{
	pthread_t id;
	pthread_create(&id, NULL, func, NULL);
	pthread_join(id, NULL);
	printf("done\n");
	return 0;
}