[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe7ae84c-745a-04b4-dcc0-5df8cc35ee0c@synopsys.com>
Date: Thu, 2 Apr 2020 01:17:01 +0000
From: Vineet Gupta <Vineet.Gupta1@...opsys.com>
To: Steven Rostedt <rostedt@...dmis.org>,
Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
CC: "linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
Ingo Molnar <mingo@...hat.com>,
Claudiu Zissulescu <claziss@...il.com>
Subject: Re: [RFC] ARC: initial ftrace support
+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@...opsys.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
Powered by blists - more mailing lists