From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10914 invoked by alias); 23 Jun 2005 21:13:22 -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 10905 invoked by uid 22791); 23 Jun 2005 21:13:18 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 23 Jun 2005 21:13:18 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j5NLDBcN012298; Thu, 23 Jun 2005 23:13:11 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j5NLDACo020453; Thu, 23 Jun 2005 23:13:10 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j5NLD68r028327; Thu, 23 Jun 2005 23:13:06 +0200 (CEST) Date: Thu, 23 Jun 2005 21:13:00 -0000 Message-Id: <200506232113.j5NLD68r028327@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: jmolenda@apple.com CC: gdb@sources.redhat.com In-reply-to: <1B26D278-3D1E-4DDB-8DFF-E15F76BA8163@apple.com> (message from Jason Molenda on Thu, 23 Jun 2005 11:50:53 -0700) Subject: Re: Further cache generating if PC is 0? References: <20050623170626.GT2814@calimero.vinschen.de> <1B26D278-3D1E-4DDB-8DFF-E15F76BA8163@apple.com> X-SW-Source: 2005-06/txt/msg00215.txt.bz2 From: Jason Molenda Date: Thu, 23 Jun 2005 11:50:53 -0700 Hi Corinna, On Jun 23, 2005, at 10:06 AM, Corinna Vinschen wrote: > Ok, so we unwind the stack pointer and what happens at that point is a > pretty hopeless guess. The guess is that the function is frameless > and > has either no local variables or we're still in the prologue. No, if we follow the convention of setting up a frame pointer and saving it on function entry (i.e. we're not debugging -fomit-frame- pointer code in gcc's terminology), we can do better. If the function we're examining is potentially frameless, then we're reduced to guessing. But if the function we're examining MUST have set up a frame, we should assume it did so and continue up the stack. cf http://sources.redhat.com/ml/gdb-patches/2005-06/msg00060.html Well, I still seem to remember that at one moment in time, around the time the i386 was converted to using the new frame unwinding code, there was a fairly common case on Linux systems where the assumption that there MUST be a frame didn't hold. I hope to be looking into Jason's patch this weekend, but in any case, it'll need thorough testing on many systems and with different compilers. Only looking at the latest Fedora Core defenitely will not do. Mark