Re: Variable "foo" is not available

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Apr 04, 2005 at 08:10:00AM +0300, Eli Zaretskii wrote:
> > 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.

He gave us the missing clue in a later message - as Mark wrote, on
x86_64, the arguments are in registers.  This means the compiler must
explicitly save them.

> > 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?

My x86 assembly is awful, so I tried to derive this from gcc output. 
The version of GCC I have installed will generate debug information
referring to the incoming argument slot, which I didn't expect it to
do.  So this is probably a non-issue.

> 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?

Actually, I don't think it would be.  This has been the subject of
considerable debate on the linux-kernel list in the past; GCC will 
sometimes modify these slots and the final consesnsus was that it was
within its rights to do so.

int foo();
int foo2 (int *);
int bar(int a)
{
  foo ();
  a += 3;
  foo2 (&a);
  return a + foo();
}

   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 08                sub    $0x8,%esp
   6:   e8 fc ff ff ff          call   7 <bar+0x7>
   b:   83 45 08 03             addl   $0x3,0x8(%ebp)
   f:   8d 45 08                lea    0x8(%ebp),%eax
  12:   89 04 24                mov    %eax,(%esp)
  15:   e8 fc ff ff ff          call   16 <bar+0x16>
  1a:   e8 fc ff ff ff          call   1b <bar+0x1b>
  1f:   8b 55 08                mov    0x8(%ebp),%edx
  22:   89 ec                   mov    %ebp,%esp
  24:   5d                      pop    %ebp
  25:   01 d0                   add    %edx,%eax
  27:   c3                      ret

See the instruction at 0xb?

GCC won't reuse the slot for an unrelated variable at present. 
However, in the future, it would be a valid optimization.

-- 
Daniel Jacobowitz
CodeSourcery, LLC