Date: Sun, 10 Jun 2012 20:49:15 -0700 From: perryh@pluto.rain.com To: rysto32@gmail.com, avg@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-listen@fabiankeil.de Subject: Re: decoding of multi-byte nops in dtrace Message-ID: <4fd5cd2b.SwlSDIgKvkib2N6C%perryh@pluto.rain.com> In-Reply-To: <4FD5109D.5090107@FreeBSD.org> References: <4FD490D5.1070207@FreeBSD.org> <20120610152721.3b627896@fabiankeil.de> <4FD4CD8B.1080803@FreeBSD.org> <CAFMmRNwURMy55acPGZfYWnNSCB8VUvqWExV27RhBqcZHVUY==A@mail.gmail.com> <4FD5109D.5090107@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon <avg@freebsd.org> wrote:
> on 10/06/2012 23:40 Ryan Stone said the following:
> > On Sun, Jun 10, 2012 at 12:38 PM, Andriy Gapon <avg@freebsd.org>
> > wrote:
> >> Do you use -O2 or higher optimization for kernel/modules build?
> >> I use only -O1.
> >>
> >> Here are some stats from my system:
> >> $ dtrace -ln fbt::: | fgrep -c entry
> >> 16876
> >> $ dtrace -ln fbt::: | fgrep -c return
> >> 16729
> >>
> >> So, 147 functions without return probe.
> >
> > Try re-compiling with -foptimize-sibling-calls. That enables
> > the tail call optimization in gcc, and therefore you get many
> > functions with no ret instruction (and thus no return probe in
> > DTrace)
Sounds as if DTrace could use an improvement to recognize and handle
the tail call optimization, maybe something along the lines of:
If a function has no otherwise-determined return probe
and it contains a jump to the entry point of another function
then it inherits that other function's return probe.
I'd expect that to handle cases like
int bar(...)
{
...
return baz;
}
int foo(...)
{
...
return bar(...);
}
(although probably not cases where the return in foo calls a
function pointer). And no, I am not volunteering to add it --
ENOTIME :(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4fd5cd2b.SwlSDIgKvkib2N6C%perryh>