From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24859 invoked by alias); 25 Jan 2011 14:22:39 -0000 Received: (qmail 24836 invoked by uid 22791); 25 Jan 2011 14:22:38 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Jan 2011 14:22:32 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0PEMTHQ032651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jan 2011 09:22:29 -0500 Received: from mesquite.lan (ovpn-113-42.phx2.redhat.com [10.3.113.42]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0PEMSqU007667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 25 Jan 2011 09:22:29 -0500 Date: Tue, 25 Jan 2011 15:14:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: "Ulrich Weigand" Subject: Re: [RFC] Fix variable lifetime related problem in gdb.base/store.exp Message-ID: <20110125072228.4c8e9af4@mesquite.lan> In-Reply-To: <201101212041.p0LKfT4c029521@d06av02.portsmouth.uk.ibm.com> References: <20110119162636.092db33a@mesquite.lan> <201101212041.p0LKfT4c029521@d06av02.portsmouth.uk.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00493.txt.bz2 On Fri, 21 Jan 2011 21:41:29 +0100 (CET) "Ulrich Weigand" wrote: > Isn't this then simply a matter of the compiler generating incorrect > debug information? At the PC corresponding to the call site, it is > simply not true that register ra holds the variable l, so the debug > info shouldn't say that. Instead, the debug info should either point > to whatever place actually holds the variable at this point, or else > mark variable l as "optimized out" there. > > There's in the end not much GDB can do if debug info is just wrong. I agree with your analysis. Let's assume for the moment that we change the compiler to mark `l' as "optimized out". If we do this, we should still see failures when we attempt to either examine or set `l'. After all, we can't look at or change values that have been optimized out. I can think of four not entirely unreasonable courses of action: 1) Leave the test case as is with the justification that optimizing away variables in unoptimized code is not debugger-friendly and therefore *should* be considered a bug. 2) Avoid the problem by changing the test to use some other variable that's not so easy to optimize out. (This is what my patch does.) 3) Change the test case to recognize the "optimized out" condition, causing the affected tests to be XFAILed instead. 4) Do (3), but also augment the test case to modify/examine some other variable that won't likely be optimized out. As I ponder these options, I'm not really liking option 2 since it doesn't allow us to learn of a potential deficiency in the compiler. That being the case, I withdraw my patch. Kevin