From: Joel Brobecker <brobecker@act-europe.fr>
To: gdb-patches@sources.redhat.com
Subject: Pb when calling a nested function in the inferior
Date: Mon, 30 Jul 2001 05:47:00 -0000 [thread overview]
Message-ID: <20010730144818.A4726@act-europe.fr> (raw)
Hi,
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:
<<
int
main (void)
{
int first;
int result;
int
get_value (void)
{
return first;
}
first = 1;
result = get_value (); /* This is line 14 */
}
>>
%gcc -g -o hello hello.c
%gdb hello
(gdb) break hello.c:14
(gdb) run
(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?
Thanks,
--
Joel
next reply other threads:[~2001-07-30 5:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-30 5:47 Joel Brobecker [this message]
2001-07-30 10:32 ` Michael Snyder
2001-07-30 11:31 ` Kevin Buettner
2001-07-30 14:24 ` Joel Brobecker
2001-07-30 15:41 ` Andrew Cagney
2001-07-30 15:49 ` Kevin Buettner
2001-07-31 0:24 ` Joel Brobecker
2001-07-31 1:20 ` Kevin Buettner
2001-07-31 1:36 ` Joel Brobecker
2001-07-31 1:29 ` Kevin Buettner
2001-08-23 3:40 ` Joel Brobecker
-- strict thread matches above, loose matches on Subject: below --
2001-03-05 18:58 [PATCH RFA] procfs.c related changes for AIX 5 Kevin Buettner
2001-03-06 1:11 ` Eli Zaretskii
2001-03-06 1:29 ` Kevin Buettner
2001-03-06 1:41 ` Eli Zaretskii
[not found] ` <3AAEC861.2756C62A@cygnus.com>
[not found] ` <msnyder@cygnus.com>
2001-03-26 18:24 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010730144818.A4726@act-europe.fr \
--to=brobecker@act-europe.fr \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox