Thread backtrace termination
Jonathan Larmour
jifl@eCosCentric.com
Mon Jul 11 16:21:00 GMT 2005
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
More information about the Gdb
mailing list