Thread backtrace termination
Daniel Jacobowitz
drow@false.org
Mon Jul 11 16:23:00 GMT 2005
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
More information about the Gdb
mailing list