From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31771 invoked by alias); 1 Mar 2006 22:35:50 -0000 Received: (qmail 31751 invoked by uid 22791); 1 Mar 2006 22:35:49 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Mar 2006 22:35:47 +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 k21MZj4a015657 for ; Wed, 1 Mar 2006 17:35:45 -0500 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 k21MZj130179; Wed, 1 Mar 2006 17:35:45 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k21MZhKt024882; Wed, 1 Mar 2006 17:35:43 -0500 Message-ID: <440621BE.4070205@redhat.com> Date: Wed, 01 Mar 2006 22:35:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Jason Kraftcheck CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: list/edit command on frame with available symtab References: <43FE018B.2050502@cae.wisc.edu> <20060223210007.GB2353@nevyn.them.org> <43FE2556.8040207@cae.wisc.edu> In-Reply-To: <43FE2556.8040207@cae.wisc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00026.txt.bz2 Jason Kraftcheck wrote: > Daniel Jacobowitz wrote: > >>On Thu, Feb 23, 2006 at 12:40:11PM -0600, Jason Kraftcheck wrote: >> >> >>>If there is no symtab for the current frame, traverse up the stack >>>looking for a frame with a symtab. This may at first seem like a >>>gratuitous feature (and perhaps it is), but I find it is convenient when >>>working with an application that uses third-party libraries. Typically >>>whatever code I'm working on has debug symbols while whatever >>>third-party code I'm calling does not. And I'm much more interested in >>>seeing where the process was in my code at the time a fault occurred. I >>>don't think this change will be a problem for anyone, as the previous >>>behavior was to print an error if there was no symtab. >>> >>> >>>2006-02-23 Jason Kraftcheck >>> >>> * stack.c (set_current_sal_from_frame): If list or edit command >>> is invoked for a frame without a symtab, move up the stack to >>> the neareast frame with a symtab. >> >> >>I'm not sure this is a good idea, but in any case, is that really >>what's going on? I already get successful "list", and edit opens a file >>named "unknown", if the parent frame has line info. >> > > > With this patch, I get what I expect. Without this patch, stopping due > to a sigabrt, edit and list both show whatever was the previous valid > sal, which is probably a bug. After moving up or down a frame, they > both report an error (in the edit case, editing a file called "unknown"). I've never tried it with edit, and I haven't tried it recently with list, but my recollection is in line with Daniel's comment -- afaik, it already works, at least for list. With what version and configuration of gdb do you find it to be broken?