LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: "Frédéric Weisbecker" <>
Cc: Steven Rostedt <>,
Subject: Re: [RFC][PATCH] Make ftrace able to trace function return
Date: Thu, 30 Oct 2008 19:37:14 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Frédéric Weisbecker <> wrote:

> 2008/10/30 Ingo Molnar <>:
> > hm, are you aware of the -finstrument-functions feature of GCC?
> >
> > that feature generates such entry points at build time:
> >
> >                   void __cyg_profile_func_enter (void *this_fn,
> >                                                  void *call_site);
> >                   void __cyg_profile_func_exit  (void *this_fn,
> >                                                  void *call_site);
> Oh I didn't know it.
> But wouldn't it conflict with the -pg used for mcount in ftrace?

i dont think the two can be enabled at once. If then it would replace 
the mcount stuff. (but the principle is very similar)

I'm wondering whether it's worth it though.

> > this might be faster/cleaner than using a trampoline approach IMO.
> Yes, oubviously!
> > OTOH, entry+exit profiling has about double the cost of just entry
> > profiling - so maybe there should be some runtime flexibility there.
> > Plus the same recordmcount trick should be used to patch up these
> > entry points to NOP by default.
> Yes that's right. Hm I don't know what to do since there is already 
> mcount....

just dont use -pg, only use -finstrument-functions.

when i wrote my first mcount tracer many eons ago i knew about 
-finstrument-functions and decided against it based on the fact that 
it doubles the cost of profiling.

OTOH, dyn-ftrace changes the picture dramatically, with its NOP 
insertion and opt-in tricks. Still, one more 5-byte NOP in every 
function is still something not to be done lightly.

In that sense your mcount enhancement is better, as it does not 
increase the default (single NOP) cost. It can also be 
enabled/disabled dynamically in addition to the 'half-way profiling' 
mcount solution we have today. So i like it at first sight - if it can 
be made stable ;-)


  reply	other threads:[~2008-10-30 18:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 19:20 Frederic Weisbecker
2008-10-30 18:20 ` Ingo Molnar
2008-10-30 18:30   ` Frédéric Weisbecker
2008-10-30 18:37     ` Ingo Molnar [this message]
2008-10-30 19:17       ` Steven Rostedt
2008-10-30 19:26         ` Ingo Molnar
2008-11-03 11:16           ` Ananth N Mavinakayanahalli
2008-11-03 13:32             ` Frédéric Weisbecker
2008-10-31  1:35       ` Frédéric Weisbecker
2008-10-30 20:30 ` Steven Rostedt
2008-10-31  0:05   ` Frédéric Weisbecker
2008-10-31  2:43     ` Steven Rostedt
2008-10-31 20:18       ` Frederic Weisbecker
2008-11-03 10:06         ` Ingo Molnar
2008-11-03 13:11           ` Frédéric Weisbecker

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [RFC][PATCH] Make ftrace able to trace function return' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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 NNTP newsgroup(s).