Thread backtrace termination

[Jonathan Larmour <jifl@eCosCentric.com>]

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