Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables

On Tue, Feb 16, 2016 at 09:09:16PM +1100, Michael Ellerman wrote:

On Mon, 2016-02-15 at 15:04 +0100, Torsten Duwe wrote:

quoted

If you use "-pg -mprofile-kernel", gcc seems to forget that, and omits the TOC
load, for a similar assembler calling sequence.

That's by design.

Ah, ok.

mprofile-kernel is supposed to create as little overhead as possible in the
non-traced case. All of the burden is shifted to the trace function (_mcount).

... or its helpers, see below.

The reason to do that is because modern distros always build with tracing, but
most of the time tracing will not actually be active. So we want the cost of
tracing-built-in-but-disabled to be ~zero.

Ok, that's a design goal.

quoted

That was the alternative I asked about; but given that the _mcount / ftrace_caller
trampoline hardly differs from a normal trampoline (so far), loading R2 would be the
general case, or an excessive special case handling would result.

I'm not sure I follow what you mean there at the end.

This suggests you have not yet actively debugged this problem ;-)

Requiring ftrace_caller() to load the kernel TOC is not a problem IMHO.

The problem is, you don't get to ftrace_caller in the first place :)

I think I have an easier way to do it, I'll reply to the patch with that (if it
works).

I doubt so. Either it works, _or_ it is easier ;)

To save you some work: by the design of minimal overhead you try to follow,
SQUASH_TOC_SAVE_INSN from my patches isn't sufficient. You'll need to load the
_current_ TOC _on_ the trampoline, and in turn it will be different from the regular
trampolines; and that needs to be recognised, or the normal module linker logic
won't work.

OTOH my proposed GCC change only affects a very limited number of functions...

Looking forward to your patch!

	Torsten