From: Scott A McConnell <samcconn@cotw.com>
To: "MIPS/Linux List (SGI)" <linux-mips@oss.sgi.com>
Subject: gdb, pthreads and MIPS
Date: Thu, 24 Jan 2002 08:58:16 -0600 [thread overview]
Message-ID: <3C502108.B4024075@cotw.com> (raw)
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
next reply other threads:[~2002-01-24 14:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-24 14:58 Scott A McConnell [this message]
2002-01-24 17:15 ` gdb, pthreads and MIPS Daniel Jacobowitz
2002-01-24 20:42 ` Scott A McConnell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C502108.B4024075@cotw.com \
--to=samcconn@cotw.com \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.