[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160126135621.GA28664@lst.de>
Date: Tue, 26 Jan 2016 14:56:21 +0100
From: Torsten Duwe <duwe@....de>
To: Petr Mladek <pmladek@...e.com>
Cc: Miroslav Benes <mbenes@...e.cz>,
Steven Rostedt <rostedt@...dmis.org>,
Michael Ellerman <mpe@...erman.id.au>,
Jiri Kosina <jkosina@...e.cz>, linuxppc-dev@...ts.ozlabs.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
live-patching@...r.kernel.org
Subject: Re: [PATCH v6 8/9] Implement kernel live patching for ppc64le
(ABIv2)
On Tue, Jan 26, 2016 at 01:48:53PM +0100, Petr Mladek wrote:
> On Tue 2016-01-26 11:50:25, Miroslav Benes wrote:
> >
> > We still need Petr's patch from [1] to make livepatch work, right? Could
> > you, please, add it to this patch set to make it self-sufficient?
It's Petr's patch, I don't want to decide how to best tackle this, see below.
I think Michael is already aware that it is needed, too.
> > Second, what is the situation with mcount prologue between gcc < 6 and
> > gcc-6? Are there only 12 bytes in gcc-6 prologue? If yes, we need to
Precisely, it's commit e95d0248daced44 (in http://repo.or.cz/official-gcc.git)
or svn trunk change 222352 "No need for -mprofile-kernel to save LR to stack."
It's efficient, I like it.
> I am going to update the extra patch. There is an idea to detect the
> offset during build by scrips/recordmcount. This tool looks for the
> ftrace locations. The offset should always be a constant that depends
> on the used architecture, compiler, and compiler flags.
My first idea was to check for compiler version defines, but some vendors
are rumoured to patch their compilers ;-)
> The tool is called post build. We might need to pass the constant
> as a symbol added to the binary. The tool already adds some symbols.
That's even better.
Thanks!
Torsten
Powered by blists - more mailing lists