This is the mail archive of the
mailing list for the GDB project.
Pb when calling a nested function in the inferior
- To: gdb-patches at sources dot redhat dot com
- Subject: Pb when calling a nested function in the inferior
- From: Joel Brobecker <brobecker at act-europe dot fr>
- Date: Mon, 30 Jul 2001 14:48:18 +0200
We have encountered a pb with gdb when one calls from gdb a nested
function which accesses some "semi-global" variables. Here,
"semi-global" means global to the nested function, but local to the
englobing function. I would appreciate some advice on what can be done
to correct the problem (if the problem can be solved, or helped, that
is). Needless to say, if something can be done, I will make the
necessary changes, and contribute them back.
Here is an example to illustrate the problem:
first = 1;
result = get_value (); /* This is line 14 */
%gcc -g -o hello hello.c
(gdb) break hello.c:14
(gdb) print first
$1 = 1
(gdb) p get_value ()
$2 = -1017254775 <<<--- This value is incorrect (should be 1)
I could reproduce this problem on several plateforms. I looked at it
more closely on Linux where I used the lastest gdb from CVS and here are
my conclusions: From the assembly code generated for hello.c, I can see
that get_value() expects the caller to place the value of variable
"first" into %ecx before the call. It does not seem that gdb is doing
this, so when the call is made, get_value reads a random value in %ecx,
thus leading to the strange value (in an equivalent program written this
time in Ada, it leads to a SIGSEGV).
FWIW, once you get past the line that invokes get_value() using "next",
the "p get_value()" command starts working fine, since the inferior did
setup the context which has not been destroyed since.
The question is: Is there a way for gdb to know that indeed get_value ()
needs some special context to be setup before being called. If yes,
then can it find out what special context is needed?