From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26804 invoked by alias); 4 Apr 2005 07:58:06 -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 26683 invoked from network); 4 Apr 2005 07:57:58 -0000 Received: from unknown (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org with SMTP; 4 Apr 2005 07:57:58 -0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-02.spheriq.net with ESMTP id j347vuaD017793 for ; Mon, 4 Apr 2005 07:57:56 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-03.spheriq.net with ESMTP id j347vsVp016218 for ; Mon, 4 Apr 2005 07:57:56 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 j347vrvx025366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 4 Apr 2005 07:57:54 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 5B901DA41; Mon, 4 Apr 2005 07:57:52 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 36DF0472C2; Mon, 4 Apr 2005 07:59:07 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D0EAF75994; Mon, 4 Apr 2005 07:59:06 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 29A6A4725E; Mon, 4 Apr 2005 07:59:04 +0000 (GMT) Received: from [164.129.15.35] (butch.bri.st.com [164.129.15.35]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id BBT00548 (AUTH "daniel thompson"); Mon, 4 Apr 2005 08:57:48 +0100 (BST) Message-ID: <4250F37B.8090707@st.com> Date: Mon, 04 Apr 2005 07:58:00 -0000 From: Daniel THOMPSON Organization: STMicroelectronics (R&D) Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 MIME-Version: 1.0 To: Eli Zaretskii Cc: Daniel Jacobowitz , gdb@sources.redhat.com, Reiner.Steib@gmx.de Subject: Re: Variable "foo" is not available References: <20050401171947.GA19058@nevyn.them.org> <01c53768$Blat.v2.4$d52008a0@zahav.net.il> <20050402142639.GA27550@nevyn.them.org> <01c537af$Blat.v2.4$c36667c0@zahav.net.il> <20050402184023.GA20247@nevyn.them.org> <01c537c6$Blat.v2.4$427763a0@zahav.net.il> <20050402210541.GA16758@nevyn.them.org> <01c538d4$Blat.v2.4$b261c020@zahav.net.il> In-Reply-To: <01c538d4$Blat.v2.4$b261c020@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: No X-SpheriQ-Ver: 2.1.1 X-SW-Source: 2005-04/txt/msg00027.txt.bz2 Eli Zaretskii wrote: >>Date: Sat, 2 Apr 2005 16:05:42 -0500 >>From: Daniel Jacobowitz >>Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de >> >> >>>We are talking about function call arguments here, not just about any >>>local variables. Can you tell what compiler optimizations could cause >>>what Reiner reported: that the first argument is available to GDB, but >>>the second is not? >> >>Very easily. Suppose you have two incoming arguments in registers; GCC >>will do this automatically for static functions even on i386, which >>normally uses a stack convention. The first is used after a function >>call, so it is preserved by saving it to the stack. The second is not >>used after the function call, so the compiler has no reason to allocate >>a save slot for it, and no reason to store it to memory before the >>function call. > > > The functions present in Reiner's backtraces are not static, they are > external, with the exception of funcall_lambda. I don't have access > to an x86_64 machine, but at least on an IA32 x86 architecture the > code produced by GCC 3.4.3 for these function calls is quite > straightforward (see one example below), and with GDB 6.3 I couldn't > reproduce the "arg not available" message. > > >>With stack-based argument passing, GCC may be claiming an argument is >>unavailable when the function's local copy is dead, when a copy still >>exists on the stack somewhere. I don't know if it will do that or not. >>GDB can not assume that the argument is available in the incoming stack >>slot, since it could be reused for other data. > > > What, if any, would be the expression of this in the machine code? > > Also, I don't quite understand how can a stack slot of a function call > argument be reused before the function returns. Isn't that slot > outside the function's frame? Reusing it would be a violation of the > ABI, right? I doubt it. The following C is perfectly valid. void foo(int a, int b, int c, int d) { a = b + c; printf("a+d = %d\n", a, d); printf("b = %d\n", b); } On modern architectures with a decent number of registers (including IIRC the x86-64) a, b and c will be passed in registers rather than on the stack. Just as it is entirely legal for the C code to overwrite a it is entirely legal that after the addition the compiler can choose to overwrite c since it is no longer used. In the case above it will be overwritten implicitly by the first call to printf. The resultant code will be faster because there will be no code in foo to store c to the stack before calling the first printf. I suspect as Mr. Jacobowitz says on some of the older compiler/debugger combos on a register rich archictecture there will be no warning but if you examine the value of c between the printfs when c would have a garbage value. The current behavior is clearly superior. -- Daniel Thompson (STMicroelectronics) 1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659 If a car is a horseless carriage then is a motorcycle a horseless horse?