gdb: issues with signals / debugging pthread based applications

[danielhams]

Using the existing gdb in rse has outstanding issues to be looked into:

(1) Spurious signals arrive that seem unhandled by gdb (2) Applications that use pthreads seem to cause issues when attempting to debug them

So far, this issue is difficult to pin down and will require deeper scenario testing to find out the cases in which the errors / problems are seen.

e.g.

building and linking a simple executable + single library, main calls a function in the shared lib where pthread_create is done with a simple function executed. Putting a break inside the func called in the library == all working!

The breakpoint is hit, can inspect the vars inside the func. The stack is a wee bit strange, but possibly correct due to the launch of the thread:

Starting program: /usr/people/dan/Temp/testpthread/sgug-rse/./testprog 
Main begin.

Breakpoint 1, doit (arg=0x0) at testlib.c:8
8         printf("doit\n");
(gdb) where
#0  doit (arg=0x0) at testlib.c:8
#1  0x0c05d480 in _SGIPT_pt_start ()
    at /xlv86/patches/7202/work/eoe/lib/libpthread/libpthread_n32_M3/pt.c:813
#2  0x00000000 in ?? ()
(gdb) list
3       #include <stdio.h>
4       #include <string.h>
5
6       void* doit( void * arg )
7       {
8         printf("doit\n");
9
10        return NULL;
11      }
12
(gdb) print arg
$1 = (void *) 0x0

[danielhams]

GDB has now been taught about the additional IRIX signals and which ones are "normal" at runtime in e2aeac0.

I've not re-checked the debuggability of pthread apps yet.

[dillera]

I believe you.