[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171212193711.6e3167ac@gandalf.local.home>
Date: Tue, 12 Dec 2017 19:37:11 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jim Wilson <jimw@...ive.com>
Cc: Alan Kao <nonerkao@...il.com>, Palmer Dabbelt <palmer@...ive.com>,
Albert Ou <albert@...ive.com>, mingo@...hat.com,
patches@...ups.riscv.org, linux-kernel@...r.kernel.org,
greentime@...estech.com, alankao@...estech.com,
pombredanne@...b.com, kito@...estech.com
Subject: Re: [PATCH v2] riscv/ftrace: Add basic support
On Tue, 12 Dec 2017 09:47:03 -0800
Jim Wilson <jimw@...ive.com> wrote:
> As Alan mentioned, all gcc does is call mcount with two args, parent
> pc and self pc, same as most other linux targets. Most of the
> interesting features of prof/gprof profiling happen inside glibc, with
> the special start files provided by glibc, and some special functions
> like profil(3). I think this is more of a glibc API issue than a gcc
> ABI issue. If the glibc API changes, then the kernel support will
> have to change too. I checked half a dozen different processor ABIs,
> and I didn't find that one documents how mcount works.
mcount appears to be totally undocumented in all archs. My way of
figuring out what it did was simply reading the glibc code and how it
handled it.
Note, gcc on some archs supports the -mfentry option added with -pg,
which will will not use "mcount" but instead "__fentry__" which comes
before the prologue. This allows for ftrace to hijack the function, and
this is how live kernel patching is implemented.
-- Steve
Powered by blists - more mailing lists