linux-kernel - Re: [RFC] ARC: initial ftrace support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200402135257.7dd14f36@gandalf.local.home>
Date:   Thu, 2 Apr 2020 13:52:57 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:     Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>,
        "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>,
        Ingo Molnar <mingo@...hat.com>,
        Claudiu Zissulescu <claziss@...il.com>
Subject: Re: [RFC] ARC: initial ftrace support

On Thu, 2 Apr 2020 01:17:01 +0000
Vineet Gupta <Vineet.Gupta1@...opsys.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@...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

We really don't want this. :-/

This will make it really difficult to implement the dynamic ftrace, and
this causes more overhead when tracing is not enabled.

Also, ftrace is much more complex, and this will make it difficult to have
function graph tracing and other features.

Gcc has an "instrument-functions" which people asked me why I didn't go
that route, as it lets you do the same (call C code), and its because of
the overhead it adds to each function that I turned it down.

-- Steve



> 	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