Re: Thread backtrace termination

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote:
> 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.

This is already changed in CVS.

> 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.

In general there's no defined way to do this.  If the start routine is
written in assembly, take a look at the example I posted earlier this
year of using dwarf2 unwind information to terminate a backtrace by
marking the return address column as undefined.  There's a matching GDB
patch, which was committed to HEAD after 6.3.

For compiler-generated code there's really no useful way to do this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC