This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Thread backtrace termination
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 11 Jul 2005 17:20:55 +0100
- Subject: Thread backtrace termination
After a move from GDB 6.1 to GDB 6.3, something new happens with
backtraces on at least ARM and MIPS, e.g.:
(gdb) bt
#0 breakme () at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/tests/thread_gdb.c:108
#1 0xffffffff80021800 in controller (id=0) at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/tests/thread_gdb.c:155
#2 0xffffffff8002a550 in Cyg_HardwareThread::thread_entry
(thread=0x8003d3b0) at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/thread.cxx:110
#3 0xffffffff8002a500 in global constructors keyed to cyg_scheduler_start
() at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/kapi.cxx:1257
#4 0xffffffff8002a500 in global constructors keyed to cyg_scheduler_start
() at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/kapi.cxx:1257
Previous frame identical to this frame (corrupt stack?)
(gdb)
The two "global constructors keyed to cyg_scheduler_start" lines are bogus
frame entries, although those also happened with GDB 6.1. The "corrupt
stack" whinge is new, and is treated as an error, including terminating
gdbinit scripts etc.
I tried reverting
<http://sources.redhat.com/ml/gdb-patches/2004-01/msg00104.html>, but that
in itself isn't the issue. I know there were a bunch of other dwarf
unwinder changes for GDB 6.2. But rather than try and explain what I've
already tried to do, I'd be interested if someone could clarify to me what
the termination conditions for a backtrace actually _are_. i.e. as an OS
author, how do I initialise a thread context to persuade GDB to stop when
it reaches the innermost frame. I've tried looking at the glibc sources to
see how its thread support works, but it's rather a twisty maze of
passages, and I don't know whether it would have this problem as well anyway.
One thought I had was if it halted if the saved stack pointer is 0, but
that presents all sorts of problems for OS implementors, unless thread
entry functions must now be written in assembler with knowledge of how GDB
does its unwinding. In trying to create that scenario, I couldn't provoke
it to affect things anyway.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine