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>