gdb, pthreads and MIPS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am targeting a NEC VR5432

I am able to debug/set break points on executables that are not linked
with -lpthreads. However, whenever I try an executable that was linked
with pthreads gdb can never find the stack (PC).

Once a SIGTRAP occurs gdb has lost track of the stack. Up until that
point it seems to be keeping track of the PC.

I have tried gdb from the SGI site (H J Lu) I also have built 5.1.0.1
native. Both fail.

Are other people having trouble debugging pthreads?
Are there any patches available?
Can anyone even help me classify this problem? (gcc, glibc, gdb all
three)

--------------------------------------------------
The programs I am running are cross compiled with:

$ mipsel-linux-gcc -v
Reading specs from
/opt/toolchains/mips/lib/gcc-lib/mipsel-linux/3.0.3/specs
Configured with: ../gcc-3.0.3/configure --prefix=/opt/toolchains/mips
--target=mipsel-linux i686-pc-linux-gnu
--includedir=/opt/toolchains/mips/mipsel-linux/include
--with-gxx-include-dir=/opt/toolchains/mips/mipsel-linux/include
--mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info
--enable-languages=c,c++ --enable-threads
Thread model: posix
gcc version 3.0.3

--------------------------------------------------------
The native compiler on the MIS box is:

bash-2.04# gcc -v
Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1)





[New Thread 1024 (LWP 175)]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1024 (LWP 175)]

warning: Warning: GDB can't find the start of the function at
0xffffffff.

    GDB is unable to find the start of the function at 0xffffffff
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 0xffffffff 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.
0xffffffff in ?? ()

(gdb) info registers
          zero       at       v0       v1       a0       a1      
a2       a3
 R0   00000000 2ab04e60 00000001 2aab9920 00000000 2ab052b8 00000000
0000004d 
            t0       t1       t2       t3       t4       t5      
t6       t7
 R8   0000f000 00000053 00000000 00000001 00000001 8022eef3 7fff7904
7fff7700 
            s0       s1       s2       s3       s4       s5      
s6       s7
 R16  2ab05860 00400d40 10012c10 00000000 7fff7b18 7fff7af4 00000008
2ab052c8 
            t8       t9       k0       k1       gp       sp      
s8       ra
 R24  00000000 2aab9920 7fff76b8 00000000 2ab0c9e0 7fff7a98 2ab052b0
2aab9288 
            sr       lo       hi      bad    cause       pc
      ffffffff ffffffff 00000000 2abfd290 00000024 ffffffff 
           fsr      fir       fp
      00000000 00000000 00000000 




-- 
Scott A. McConnell


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux