From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16871 invoked by alias); 23 Jun 2005 21:28:07 -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 16857 invoked by uid 22791); 23 Jun 2005 21:28:03 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 23 Jun 2005 21:28:03 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5NLS16N015323 for ; Thu, 23 Jun 2005 14:28:01 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 23 Jun 2005 14:27:59 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j5NLRwfG028728; Thu, 23 Jun 2005 14:27:58 -0700 (PDT) In-Reply-To: <200506232113.j5NLD68r028327@elgar.sibelius.xs4all.nl> References: <20050623170626.GT2814@calimero.vinschen.de> <1B26D278-3D1E-4DDB-8DFF-E15F76BA8163@apple.com> <200506232113.j5NLD68r028327@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <549E179A-7DE1-478A-8AEC-996BE1411679@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jason Molenda Subject: Re: Further cache generating if PC is 0? Date: Thu, 23 Jun 2005 21:28:00 -0000 To: Mark Kettenis X-SW-Source: 2005-06/txt/msg00216.txt.bz2 On Jun 23, 2005, at 2:13 PM, Mark Kettenis wrote: > 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. With my patch, if a function could be potentially frameless and we can't parse the prologue or we don't know where the function starts, I assume it's frameless. If the function must have set up a frame, I assume it set up a frame using the standard save-the-caller's-ebp idiom. It's entirely reasonable to argue that my assumptions are incorrect. But if -fomit-frame-pointer code exists on the stack, *no* assumptions are correct. The current code isn't correct, my code isn't correct. The only correct thing to do is abort the stack backtrace and insist that gdb can't continue. > 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. Thanks Mark -- no rush, I'm not going away or going to lose interest. :-) As far as testing on other systems, it's working GREAT on MacOS X for Intel. :) Jason