This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Variable "foo" is not available


   Date: Mon, 04 Apr 2005 08:10:00 +0300
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Sat, 2 Apr 2005 16:05:42 -0500
   > From: Daniel Jacobowitz <drow@false.org>
   > 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.

amd64 passes arguments in registers by default.  That makes it much
more likely that an argument is discarded if it isn't needed anymore
in order for the compiler to re-use the register.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]