UPDATE Re: making use of userland dtrace on FreeBSD

[Alfred Perlstein]

On 12/26/12 8:21 PM, Peter Wemm wrote:
> On Wed, Dec 26, 2012 at 8:00 PM, Alfred Perlstein <bright at mu.org> wrote:
>
>> What would be the drawbacks?  I don't want to hurt freebsd for heavy
>> performance, but I think this functionality should work out of the box for
>> most people.
> The drawbacks are mostly performance related.  It defeats a certain
> hardware optimizations for call/return on leaf functions.  It'll
> mostly affect things like math, crypto, compression and multimedia
> libraries (that's ffmpeg, bzip2/gzip/libarchive, openssl, etc) but, we
> generally don't seem to care about that sort of performance anyway, so
> what's one more loss?

Can you clarify some?  If it was somewhat easy to re-add 
-fomit-frame-pointer to critical libraries like this, then that would be 
OK?

To be honest, I'm not sure if you're serious about "generally don't seem 
to care" or just feel defeated on the issue and we should care.

What do you think?



>
> Of course it wouldn't be required with dwarf unwinding awareness, but
> we don't have that.
>
> We have -fno-omit-frame-pointer on the amd64 kernel whenever debugging
> is compiled in because there's no unwinder for doing stack traces.  We
> need a dwarf2+ unwinder and somebody to instrument the call frame
> state through the remaining assembler code.
>
How much work is that exactly?  I've only been a gdb user, not a hacker.

What is the right call here?  Is the increased functionality worth the 
performance hit until we get the dwarf2+ unwinder?  Or not worth it 
until we get the unwinder?

There's no numbers, but does anyone care to provide some, or give me 
some things to test to bring numbers back?

-Alfred