From: Richard Sandiford <richards@transitive.com>
To: gcc@gcc.gnu.org
Cc: bart.vanassche@gmail.com
Subject: PR 23296: Strange -O3 -finstrument-functions behaviour
Date: Mon, 29 Jun 2009 14:23:00 -0000 [thread overview]
Message-ID: <g4r5x316e0.fsf@richards-desktop.transitives.com> (raw)
A colleague recently came across the interaction between
-finstrument-functions and inline functions mentioned here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23296
As the bug submitter says, the problem is that for something like:
#include <stdio.h>
void g (void) { printf("Here\n"); }
int main (void) { g (); return 0; }
compiled with "-O3 -finstrument-functions", you get two successive calls
to __cyg_profile_func_enter _with the same arguments_. That is, both
calls say that they are entering main():
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
Is this really the intended behaviour? Andrew closed the bug as invalid,
saying that this is what we expect, but the docs seem to suggest that we
ought to do something like:
...
__cyg_profile_func_enter (&main, ...);
...
__cyg_profile_func_enter (&g, ...);
...
__cyg_profile_func_exit (&g, ...);
...
__cyg_profile_func_exit (&main, ...);
...
instead. [I'm going off:
This instrumentation is also done for functions expanded inline in other
functions. The profiling calls will indicate where, conceptually, the
inline function is entered and exited. This means that addressable
versions of such functions must be available. If all your uses of a
function are expanded inline, this may mean an additional expansion of
code size. If you use @samp{extern inline} in your C code, an
addressable version of such functions must be provided. (This is
normally the case anyways, but if you get lucky and the optimizer always
expands the functions inline, you might have gotten away without
providing static copies.)
Although it doesn't explicitly say _why_ we need addressable versions,
the context suggests to me that we're supposed to be passing them
as the "this_fn" argument to the hooks.]
Richard
next reply other threads:[~2009-06-29 14:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 14:23 Richard Sandiford [this message]
2009-06-29 21:48 ` Ian Lance Taylor
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=g4r5x316e0.fsf@richards-desktop.transitives.com \
--to=richards@transitive.com \
--cc=bart.vanassche@gmail.com \
--cc=gcc@gcc.gnu.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).