From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6839 invoked by alias); 28 Jan 2008 20:13:27 -0000 Received: (qmail 6830 invoked by uid 22791); 28 Jan 2008 20:13:26 -0000 X-Spam-Check-By: sourceware.org Received: from post.sinavigator.com (HELO post.sinavigator.com) (216.218.185.251) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Jan 2008 20:13:01 +0000 Received: from localhost (localhost [127.0.0.1]) by post.sinavigator.com (Postfix) with ESMTP id 95E351C6AE; Mon, 28 Jan 2008 12:16:30 -0800 (PST) Received: by post.sinavigator.com (Postfix, from userid 65534) id 575CB1C162; Mon, 28 Jan 2008 12:16:26 -0800 (PST) Received: from [127.0.0.1] (fs1.sinavigator.com [192.168.0.10]) by post.sinavigator.com (Postfix) with ESMTP id E642A15972; Mon, 28 Jan 2008 12:16:25 -0800 (PST) Message-ID: <479E3744.1050500@sinavigator.com> Date: Mon, 28 Jan 2008 20:13:00 -0000 From: "William K. Foster" Reply-To: wkf@sinavigator.com User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "William K. Foster" , gdb@sourceware.org Subject: Re: Step outer function call References: <479E332C.7080205@sinavigator.com> <20080128200951.GA11321@caradoc.them.org> In-Reply-To: <20080128200951.GA11321@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00292.txt.bz2 Hi, I don't know much about the debug formats, but it seems to me that since the debugger knows what line number it is on in the source code, it should be able to locate the last function call on that line number and enter it for this hypothetical command that many people seem to want. Am I missing something? Thanks. -WIlliam Daniel Jacobowitz wrote: > On Mon, Jan 28, 2008 at 11:55:24AM -0800, William K. Foster wrote: > >> If not, is this a reasonable feature request for gdb? >> > > Folks do seem to want this fairly often. But current debug formats do > not provide enough information to identify the situation, so (as far > as we've been able to determine) there's no way to implement it. > >