From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21979 invoked by alias); 1 Mar 2004 01:24:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21972 invoked from network); 1 Mar 2004 01:24:43 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 1 Mar 2004 01:24:43 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BCDE32B92; Sun, 29 Feb 2004 20:24:39 -0500 (EST) Message-ID: <404290D7.5060300@gnu.org> Date: Mon, 01 Mar 2004 01:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc,6.1?] Use right frame ID in step_over_function References: <40416BAF.1020308@gnu.org> <20040229171801.GK15749@nevyn.them.org> In-Reply-To: <20040229171801.GK15749@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00003.txt Message-ID: <20040301012400.p98wBExVpIHc58ny8N5h80UqBULPabj9JotitdP5W0U@z> >>The bug apepars when trying to step over nested shared library non-debug >>> info functions (making sense?). > > > No, not really. Could you give us a testcase? What platform have you > seen this behavior on? PPC/NetBSD. > On Sat, Feb 28, 2004 at 11:33:51PM -0500, Andrew Cagney wrote: > >>> Hello, >>> >>> This goes into the "how did it ever work" category. The idea of >>> step_over_function is that it: >>> >>> - finds the caller's resume address >>> - finds the caller's frame ID >>> >>> and then sets a breakpoint for that caller instance of the function. >>> The current code: >>> >>> - finds the caller's resume address >>> - finds the _callee_ frame ID >>> >>> and then uses that to set the breakpoint. Now that is plain weird! It >>> only works because either: >>> >>> - the step_frame_id patches up the bug >>> >>> - the values match as GDB is using the inner-most, rather than >>> outer-most frame address as part of the frame ID The NetBSD/PPC case, the old code does this: /* NOTE: cagney/2002-04-14: The ->frame points to the inner-most address of the current frame. Things might be easier if the ->frame pointed to the outer-most address of the frame. In the mean time, the address of the prev frame is used as the base address of this frame. */ >>> The bug apepars when trying to step over nested shared library non-debug >>> info functions (making sense?). So I suspect it applied to all PPC, just that NetBSD's are a bit wierd. Andrew