From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2161 invoked by alias); 3 Apr 2006 12:59:29 -0000 Received: (qmail 2153 invoked by uid 22791); 3 Apr 2006 12:59:28 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Apr 2006 12:59:26 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-02.spheriq.net with ESMTP id k33CxLS4003397 for ; Mon, 3 Apr 2006 12:59:21 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id k33CxKWG018791 for ; Mon, 3 Apr 2006 12:59:20 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k33CxI33013943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 3 Apr 2006 12:59:19 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2C823DA42 for ; Mon, 3 Apr 2006 12:59:18 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8F09047424 for ; Mon, 3 Apr 2006 13:03:21 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHK49194 (AUTH stubbsa); Mon, 3 Apr 2006 13:59:16 +0100 (BST) Message-ID: <44311B95.2040701@st.com> Date: Mon, 03 Apr 2006 12:59:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Re: [PATCH][SH] invalid registers References: <437B5C5F.5080500@st.com> <20060330171503.GJ32409@nevyn.them.org> In-Reply-To: <20060330171503.GJ32409@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.01 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-04/txt/msg00019.txt.bz2 Daniel Jacobowitz wrote: > This is OK. Only S/390 uses the frame_init_reg hook this way today, > but it seems sensible. But please wait a day or two in case anyone has > comments on the downside. Hmmm, perhaps that ought to be fixed. I don't believe all those target really *know* what the value of all registers is in every frame. > The downside is that you can't do this: > > (gdb) break *abort > (gdb) continue > ... > (gdb) up > (gdb) info registers > > Instead, you have to look at the registers while you're in the bottom > frame (i.e. abort) instead of the aborting function. In your example _we_ know that the values are real, but the debugger does not, and, in my opinion, should not present them as if it does. > Would it be more useful if GDB could output "0x40000000 (may be > clobbered)" somehow in info regs for DWARF2_FRAME_REG_UNDEFINED? > But, not a big deal either way. Yes, that might be a suitable compromise, but not for DWARF2_FRAME_REG_UNDEFINED - that value really means it when it comes from dwarf. Perhaps another value. In any case, a 'day or two' has passed and nobody has said anything. Am I OK to commit this? Andrew