From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8098 invoked by alias); 24 Jun 2005 08:07:38 -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 7262 invoked by uid 22791); 24 Jun 2005 08:07:12 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 08:07:12 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5O86wue005747 for ; Fri, 24 Jun 2005 04:06:58 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5O86vu22178 for ; Fri, 24 Jun 2005 04:06:57 -0400 Received: from calimero.vinschen.de (vpn50-23.rdu.redhat.com [172.16.50.23]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j5O86tWM024589 for ; Fri, 24 Jun 2005 04:06:56 -0400 Received: by calimero.vinschen.de (Postfix, from userid 500) id 057AB544122; Fri, 24 Jun 2005 10:07:00 +0200 (CEST) Date: Fri, 24 Jun 2005 08:07:00 -0000 From: Corinna Vinschen To: gdb@sources.redhat.com Subject: Re: Further cache generating if PC is 0? Message-ID: <20050624080659.GA2814@calimero.vinschen.de> Reply-To: gdb@sources.redhat.com Mail-Followup-To: gdb@sources.redhat.com References: <20050623170626.GT2814@calimero.vinschen.de> <1B26D278-3D1E-4DDB-8DFF-E15F76BA8163@apple.com> <200506232113.j5NLD68r028327@elgar.sibelius.xs4all.nl> <549E179A-7DE1-478A-8AEC-996BE1411679@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <549E179A-7DE1-478A-8AEC-996BE1411679@apple.com> User-Agent: Mutt/1.4.2i X-SW-Source: 2005-06/txt/msg00226.txt.bz2 On Jun 23 14:27, Jason Molenda wrote: > > 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. That's basically what I was asking. As long as the current code doesn't undergo a major rewrite as mentioned in the above thread, I'd say that something as cache->pc = frame_func_unwind (next_frame); if (!cache->pc) { cache->base = 0; return cache; } would be more correct. However, the above thread implies that it's too late to worry about it ;-) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc.