Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables
From: Balbir Singh <bsingharora@gmail.com>
Date: 2016-02-16 04:54:11
Also in:
lkml
On Mon, 2016-02-15 at 23:21 +0100, Torsten Duwe wrote:
quoted hunk ↗ jump to hunk
On Mon, Feb 15, 2016 at 03:04:08PM +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. Looking at the code I can _understand_ why this is so, but my GCC knowledge is not that deep that I could easily _fix_ this reliably.Nonetheless, here's a proposal.--- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c@@ -25154,6 +25154,10 @@ rs6000_emit_prologue (void){ cfun->machine->r2_setup_needed = df_regs_ever_live_p (TOC_REGNUM); + /* Profiling _will_ generate a call to a global _mcount. */ + if (crtl->profile) + cfun->machine->r2_setup_needed = true; + /* With -mminimal-toc we may generate an extra use of r2 below. */ if (TARGET_TOC && TARGET_MINIMAL_TOC && get_pool_size () != 0) cfun->machine->r2_setup_needed = true;
I was wondering if ftrace() works correctly, specifically dynamic ftrace. We should be able to get livepatching to work as well. I can see r2 being saved in the stub in ftrace_caller in patch 2/8 + mr r0,r2 /* save callee's TOC */ + addis r2,r12,(.TOC.-ftrace_caller-12)@ha + addi r2,r2,(.TOC.-ftrace_caller-12)@l The only limitation today is figuring out the correct offset to patch (8 or 16) depending on whether the TOC stub is generated or not by the compiler If the sequence is well known, we could potentially scan instructions or go to the hash that ftrace maintains and search in there with an offset of 8 to 16. Balbir Singh