From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23502 invoked by alias); 4 Apr 2005 05:14:56 -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 23396 invoked from network); 4 Apr 2005 05:14:48 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 4 Apr 2005 05:14:48 -0000 Received: from zaretski (IGLD-80-230-67-97.inter.net.il [80.230.67.97]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id AWZ91740 (AUTH halo1); Mon, 4 Apr 2005 08:14:01 +0300 (IDT) Date: Mon, 04 Apr 2005 05:14:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz , gdb@sources.redhat.com Message-ID: <01c538d4$Blat.v2.4$b261c020@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: Reiner.Steib@gmx.de In-reply-to: <20050402210541.GA16758@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 2 Apr 2005 16:05:42 -0500) Subject: Re: Variable "foo" is not available Reply-to: Eli Zaretskii 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> X-SW-Source: 2005-04/txt/msg00025.txt.bz2 > 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? Here's the disassembly of one of the frames from Reiner's backtrace: funcall_lambda calls Fbyte_code. I disassembled on a 32-bit x86 machine (Reiner, perhaps you could show the disassembly on yours). The source code is: val = Fbyte_code (AREF (fun, COMPILED_BYTECODE), AREF (fun, COMPILED_CONSTANTS), AREF (fun, COMPILED_STACK_DEPTH)); } return unbind_to (count, val); Reiner's backtrace is: #2 0x000000000057a1d4 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available. ) at [...]/emacs/src/bytecode.c:531 #3 0x000000000054d59d in funcall_lambda (fun=29850740, nargs=1, arg_vector=0x7fbfffb198) at [...]/emacs/src/eval.c:2974 Here's the disassembly from my machine, with the PC location marked by "<<<<<<": 0x000c219e : push %eax 0x000c219f : mov 0x14(%ebx),%edi 0x000c21a2 : push %edi 0x000c21a3 : mov 0x10(%ebx),%esi 0x000c21a6 : push %esi 0x000c21a7 : mov 0xc(%ebx),%ebx 0x000c21aa : push %ebx 0x000c21ab : call 0xed130 0x000c21b0 : pop %edx <<<<<< 0x000c21b1 : pop %ecx 0x000c21b2 : push %eax 0x000c21b3 : mov 0xffffffec(%ebp),%eax 0x000c21b6 : push %eax 0x000c21b7 : call 0xc0dc0 0x000c21bc : jmp 0xc201c This is quite traditional stack-based argument passing, unless I'm missing something. The code produced for the call to funcall_lambda (not shown) does pass some arguments via registers, but I still am able to see all the arguments in the backtrace.