This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Thread backtrace termination
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jonathan Larmour <jifl at eCosCentric dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 11 Jul 2005 12:23:26 -0400
- Subject: Re: Thread backtrace termination
- References: <42D29C67.4070509@eCosCentric.com>
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