public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

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