From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27166 invoked by alias); 18 May 2006 23:31:04 -0000 Received: (qmail 27151 invoked by uid 22791); 18 May 2006 23:31:04 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 18 May 2006 23:31:02 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fgrwf-0005R4-HS; Thu, 18 May 2006 19:30:17 -0400 Date: Fri, 19 May 2006 03:32:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: jimb@codesourcery.com, pgilliam@us.ibm.com, andrew.stubbs@st.com, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier Message-ID: <20060518233017.GA20777@nevyn.them.org> Mail-Followup-To: Mark Kettenis , jimb@codesourcery.com, pgilliam@us.ibm.com, andrew.stubbs@st.com, brobecker@adacore.com, gdb-patches@sourceware.org References: <200605162137.k4GLbZiS014187@elgar.sibelius.xs4all.nl> <20060516221837.GA15617@nevyn.them.org> <1147815745.3672.163.camel@dufur.beaverton.ibm.com> <20060517155729.GF27234@adacore.com> <446C3EB3.1040606@st.com> <1147969938.3672.168.camel@dufur.beaverton.ibm.com> <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00406.txt.bz2 On Thu, May 18, 2006 at 10:04:09PM +0200, Mark Kettenis wrote: > If we're sure that zero return address actually signals the end of the > stack, then indeed we should not print the extra frame. I'm not > arguing with that. But that's defenitely Incomplete sentence? But, I think there was enough context. > Many systems, but certainly not all systems. At least i386, amd64, > sparc and sparc64 don't use this convention. I hate to break it to you but... that's not 100% true. Most psABI documents don't cover clean stack ending, so operating systems often have to pick their own (or sometimes they do specify it and OS's go off and do their own thing anyway, I expect). I've just checked, and sparc-vxworks definitely does end backtraces for kernel mode tasks by setting the return address to 0 before it spawns a new task. i386-vxworks sets %ebp to zero to indicate the end of the stack, I believe. I checked RTEMS too, but the results were somewhat inconclusive; I'm not sure it deliberately initializes all registers. That was an educational dive through RTOS source, though. -- Daniel Jacobowitz CodeSourcery