Andriy Gapon <a...@freebsd.org> wrote: > on 10/06/2012 20:56 Fabian Keil said the following: > > Andriy Gapon <a...@freebsd.org> wrote: > > > >> on 10/06/2012 16:27 Fabian Keil said the following: > >>> Andriy Gapon <a...@freebsd.org> wrote: > >>> > >>>> It seems that the $subj is missing :-) > >>>> In my environment that causes many functions to not have fbt return > >>>> probe, > >>>> because function body decoding fails before 'ret' is found. > >>>> > >>>> Here is my attempt at fixing the problem: > >>>> http://people.freebsd.org/~avg/fbt-nop.patch > >>>> Reviews and suggestions are welcome. > >>> > >>> The patch seems to reduce the number of missing > >>> fbt return probes by about 50% for me. > >>> > >>> Without the patch: > >>> > >>> fk@r500 /usr/src $sudo dtrace -ln fbt::: | grep -c entry > >>> 23395 > >>> fk@r500 /usr/src $sudo dtrace -ln fbt::: | grep -c return > >>> 16739 > >>> > >>> With the patch (and updated kernel sources): > >>> > >>> fk@r500 ~ $sudo dtrace -ln fbt::: | grep -c entry > >>> 23409 > >>> fk@r500 ~ $sudo dtrace -ln fbt::: | grep -c return > >>> 19879 > >> > >> Interesting observations, thank you. > >> Do you use -O2 or higher optimization for kernel/modules build? > > > > Yes, I kept the default -O2. > > > >> I use only -O1. > > > > With -O1 (and your patch) I get: > > > > fk@r500 ~ $sudo dtrace -ln fbt::: | grep -c entry > > 23421 > > fk@r500 ~ $sudo dtrace -ln fbt::: | grep -c return > > 22621 > > > >> 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. > >> >From a quick look at them they all seem to really never return. Either > >> >they are > >> noreturn type such panic, or functions that always call the functions of > >> the > >> first type, or functions with endless loops in them such as top level > >> functions > >> of many system threads. > > > > I looked at a couple of the functions that still lack return > > probes and the ones I looked at don't seem to belong into these > > categories. > > > > For example I get no return probes for g_eli_crypto_decrypt() > > and g_eli_crypto_encrypt(). Both return the return code of > > g_eli_crypto_cipher() for which I get a return probe. > > I don't have GELI in kernel, but it looks like an instance of well-known tail > call optimization issue. Although I assumed that GCC wouldn't apply it at > -O1. > Perhaps you use a module that was built with -O2.
That was it. I missed that COPTFLAGS aren't applied to the modules. After recompiling geom_eli manually with CFLAGS=-O1 the return codes show up as expected How did you set your -O1? Fabian
signature.asc
Description: PGP signature
