From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12954 invoked by alias); 26 Apr 2004 18:12:41 -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 12947 invoked from network); 26 Apr 2004 18:12:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 26 Apr 2004 18:12:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3QICeKG011557 for ; Mon, 26 Apr 2004 14:12:40 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3QICev29166 for ; Mon, 26 Apr 2004 14:12:40 -0400 Received: from localhost.localdomain (vpn50-20.rdu.redhat.com [172.16.50.20]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i3QICdV2010447 for ; Mon, 26 Apr 2004 14:12:39 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.10/8.12.10) with SMTP id i3QICYOR029318 for ; Mon, 26 Apr 2004 11:12:34 -0700 Date: Mon, 26 Apr 2004 19:46:00 -0000 From: Kevin Buettner To: gdb@sources.redhat.com Subject: Re: #1 0x1234456765432189 in Message-Id: <20040426111234.3eb8f0a5@saguaro> In-Reply-To: <40892F73.30209@gnu.org> References: <40892F73.30209@gnu.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00162.txt.bz2 On Fri, 23 Apr 2004 11:00:03 -0400 Andrew Cagney wrote: > At present a signal handler, in a backtrace is displayed as: > > #0 catcher (signal=26) at > /home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/sigaltstack.c:71 > #1 > #2 0x0000000000400751 in thrower (next_level=INNER, sig=26, itimer=1, > on_stack=134217728) at /home/cygnus/cagney/GD > > It isn't exactly informative. Since we're now expecting GDB to do > something sane with a signal handlers, I think how it is displayed > should be changed. In particular the output should be changed to: > > #1 0xffff01111111 in > > thoughts? I have no objection to printing an address, but I don't think that referring to the thing in frame #1 as "" is correct. The signal handler in this case is actually catcher(). Frame #1 is created by the OS to hold the process's state prior to receiving the signal in question. That being the case, I'd like to see either: #1 0xffff01111111 in or: #1 0xffff01111111 in Kevin