From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2162 invoked by alias); 11 Dec 2005 20:25:56 -0000 Received: (qmail 2155 invoked by uid 22791); 11 Dec 2005 20:25:56 -0000 X-Spam-Check-By: sourceware.org Received: from nameservices.net (HELO cw-ventures.com) (208.234.10.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 11 Dec 2005 20:25:54 +0000 Received: from [192.168.1.102] (S01060012170db558.cg.shawcable.net [68.146.99.119]) by cw-ventures.com (8.12.10/8.11.6) with ESMTP id jBBKPnNs024460 for ; Sun, 11 Dec 2005 15:25:50 -0500 Subject: Tell me about stack frames.... From: Kim Lux To: gdb@sourceware.org Content-Type: text/plain Date: Sun, 11 Dec 2005 20:25:00 -0000 Message-Id: <1134332748.14961.17.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00136.txt.bz2 I am debugging an issue in a custom gdb stub, specifically, issuing the 'bt' command in the m68hc11 stub causes gdb to go into an endless loop unwinding the stack. I am doing this from within main(). Questions: 1) How deep should the stack be when one is in main(); ? Is main() itself put on the stack ? 2) What should nextframe point to when one is on the last frame ? 3) Where/when are the frames initialized ? Thanks. Here is an example of a session that hangs gdb: ========================================================= GNU gdb 6.2-m68hc1x-2004-08-01 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=m6811-elf"... The target architecture is assumed to be m68hc12 entering dbugS12_wait() Wait: S> leaving dbugS12_wait() [Switching to process -1] 0x0000ffff in ?? () Target CPU Has Been Reset S> All Breakpoints Removed S> Breakpoint 1 at 0xc03b: file test.c, line 24. (gdb) bt #0 0x0000ffff in ?? () m68hc11_unwind_pc(): returning 00FFFF #1 0x0000ffff in ?? () m68hc11_unwind_pc(): returning 00FFFF #2 0x0000ffff in ?? () m68hc11_unwind_pc(): returning 00FFFF #3 0x0000ffff in ?? () ... ====================================================================== -- Kim Lux, Diesel Research Inc.