From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 638 invoked by alias); 11 Jul 2005 16:21:11 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 541 invoked by uid 22791); 11 Jul 2005 16:21:01 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 16:21:01 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 6D88B65C082; Mon, 11 Jul 2005 17:20:59 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id B909A65C07D for ; Mon, 11 Jul 2005 17:20:55 +0100 (BST) Message-ID: <42D29C67.4070509@eCosCentric.com> Date: Mon, 11 Jul 2005 16:21:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Thread backtrace termination Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00121.txt.bz2 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 , 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