From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: eliz@gnu.org
Cc: drow@false.org, gdb@sources.redhat.com, Reiner.Steib@gmx.de
Subject: Re: Variable "foo" is not available
Date: Mon, 04 Apr 2005 06:00:00 -0000 [thread overview]
Message-ID: <200504040600.j34604Va024681@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <01c538d4$Blat.v2.4$b261c020@zahav.net.il> (eliz@gnu.org)
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
next prev parent reply other threads:[~2005-04-04 6:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-01 16:40 Reiner Steib
2005-04-01 17:19 ` Daniel Jacobowitz
2005-04-02 9:49 ` Eli Zaretskii
2005-04-02 13:53 ` Reiner Steib
2005-04-02 14:27 ` Daniel Jacobowitz
2005-04-06 16:25 ` Reiner Steib
2005-04-02 14:26 ` Daniel Jacobowitz
2005-04-02 18:17 ` Eli Zaretskii
2005-04-02 18:40 ` Daniel Jacobowitz
2005-04-02 20:58 ` Eli Zaretskii
2005-04-02 21:05 ` Daniel Jacobowitz
2005-04-04 5:14 ` Eli Zaretskii
2005-04-04 6:00 ` Mark Kettenis [this message]
2005-04-04 7:58 ` Daniel THOMPSON
2005-04-04 19:28 ` Eli Zaretskii
2005-04-04 13:37 ` Daniel Jacobowitz
2005-04-04 19:35 ` Eli Zaretskii
2005-04-04 19:41 ` Daniel Jacobowitz
2005-04-03 18:16 ` Reiner Steib
2005-04-08 11:05 ` Eli Zaretskii
2005-04-04 9:26 ` Reiner Steib
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=200504040600.j34604Va024681@elgar.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=Reiner.Steib@gmx.de \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb@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