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