svn commit: r274489 - in head/sys/amd64: amd64 include

[Tijl Coosemans]

On Fri, 21 Nov 2014 16:26:47 -0700 Scott Long <scott4long at yahoo.com> wrote:
> On Nov 20, 2014, at 11:33 PM, Rui Paulo <rpaulo at me.com> wrote:
>> On Nov 13, 2014, at 14:11, Scott Long <scottl at FreeBSD.org> wrote:
>>> 
>>> Author: scottl
>>> Date: Thu Nov 13 22:11:44 2014
>>> New Revision: 274489
>>> URL: https://svnweb.freebsd.org/changeset/base/274489
>>> 
>>> Log:
>>> Extend earlier addition of stack frames to most of support.S.  This makes
>>> stack traces in KDB, HWPMC, and DTrace much more reliable and useful.
>> 
>> No performance differences?  The kernel enables/disables the compiler
>> option to omit the frame pointer based on the kernel config file.  If
>> DDB, DTrace, or HWPMC is enabled, the frame pointer is always saved in
>> C functions.
>> 
>> Some of these functions are in the hot path, so if you didn't see any
>> performance problem, I wonder if we should disable -fomit-frame-pointer
>> always.
> 
> That’s a good question to look further into.  I didn’t see any measurable
> differences with this change.  I think that the cost of the function call
> itself masks the cost of a few extra instructions, but I didn’t test with
> switching it on/off for the entire kernel.  That said, I purposely
> implemented this as macros so it could be easily changed in the future.
> If someone finds that this measurably impacts a certain workload, I
> wouldn’t object to making it conditional, though it does complicate any
> hand-written ASM code that tries to access the stack via %esp offsets.
> We don’t have anything like that now, but Kip was concerned enough about
> it in the future that I left it enabled unconditionally.

An alternative is to annotate the functions with .cfi directives.
Stack unwinding doesn't need frame pointers then.
http://www.logix.cz/michal/devel/gas-cfi/
https://sourceware.org/binutils/docs-2.24/as/CFI-directives.html