Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200327155355.18668-1-Eugeniy.Paltsev@synopsys.com>
 <20200327131020.79e68313@gandalf.local.home> <fe7ae84c-745a-04b4-dcc0-5df8cc35ee0c@synopsys.com>
In-Reply-To: <fe7ae84c-745a-04b4-dcc0-5df8cc35ee0c@synopsys.com>
From:   Claudiu Zissulescu Ianculescu <claziss@gmail.com>
Date:   Thu, 2 Apr 2020 11:10:27 +0300
Message-ID: <CAL0iMy3i5+_owqJcUKWzGNFakVV2P=oFdyAWCY2LP7YTusKP_Q@mail.gmail.com>
Subject: Re: [RFC] ARC: initial ftrace support
To:     Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
        "linux-snps-arc@lists.infradead.org" 
        <linux-snps-arc@lists.infradead.org>,
        Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

ARC-gcc has two modes to call the mcount routines. When using elf32
configuration, the toolchain is set to use newlib mcount. When
configured for linux, gcc toolchain is using a library call to _mcall
(single underscore)  having blink as input argument.
So, using the proper linux toolchain, your patch should work.

//C

On Thu, Apr 2, 2020 at 4:17 AM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
> +CC Claudiu
>
> On 3/27/20 10:10 AM, Steven Rostedt wrote:
> > On Fri, 27 Mar 2020 18:53:55 +0300
> > Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:
>
> Maybe add a comment that gcc does the heavy lifting: I have following in glibc
>
> +/* this is very simple as gcc does all the heavy lifting at _mcount call site
> + *  - sets up caller's blink in r0, so frompc is setup correctly
> + *  - preserve argument registers for original call */
>
> >> +noinline void _mcount(unsigned long parent_ip)
> >> +{
> >> +    unsigned long ip = (unsigned long)__builtin_return_address(0);
> >> +
> >> +    if (unlikely(ftrace_trace_function != ftrace_stub))
> >> +            ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> >> +                                  NULL, NULL);
> >> +}
> >> +EXPORT_SYMBOL(_mcount);
> >
> > So, ARCv2 allows the _mcount code to be written in C? Nice!
>
> Yeah, the gcc backend for -pg was overhauled recently so it is a first class "lib
> call" meaning we get all the register save/restore for free as well as caller PC
> (blink) as explicit argument to _mcount
>
> void bar(int a, int b, int c) {
>         printf("%d\n", a, b, c);
> }
>
> bar:
>         push_s  blink
>         std.a r14,[sp,-8]
>         push_s  r13
>         mov_s   r14,r1
>         mov_s   r13,r0
>         mov_s   r0,blink
>         bl.d @_mcount
>         mov_s   r15,r2
>
>         mov_s   r3,r15   <-- restore args for call
>         mov_s   r2,r14
>         mov_s   r1,r13
>         mov_s   r0,@.LC0
>         ld      blink,[sp,12]
>         pop_s   r13
>         b.d     @printf
>         ldd.ab r14,[sp,12]
>
> @Eugeniy, this patch looks ok to me, but a word of caution. This won't work with
> elf32 toolchain which some of the build systems tend to use (Alexey ?)
>
> The above _mcount semantics is only implemented for the linux tool-chains.
> elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as arg)
> likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can add a
> toggle to get new _mcount.
>
> And this is conditional to ARCv2 due to future ties into dynamic ftrace and
> instruction fudging etc ? We may have to revisit that for BE anyhow given such a
> customer lining up.
>
> -Vineet