+CC Claudiu

On 3/27/20 10:10 AM, Steven Rostedt wrote:
> On Fri, 27 Mar 2020 18:53:55 +0300
> Eugeniy Paltsev <eugeniy.palt...@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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Reply via email to