[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1602042244430.22727@cbobk.fhfr.pm>
Date: Thu, 4 Feb 2016 22:47:56 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: AKASHI Takahiro <takahiro.akashi@...aro.org>
cc: Torsten Duwe <duwe@....de>, Steven Rostedt <rostedt@...dmis.org>,
Michael Ellerman <mpe@...erman.id.au>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
live-patching@...r.kernel.org
Subject: Re: [PATCH v6 1/9] ppc64 (le): prepare for -mprofile-kernel
On Thu, 4 Feb 2016, AKASHI Takahiro wrote:
> On arm/arm64, link register must be saved before any function call. So anyhow
> we will have to add something, 3 instructions at the minimum, like:
> save lr
> branch _mcount
> restore lr
> <prologue>
> ...
> <body>
> ...
This means that we have at least two architectures that need one
instruction before the mcount/mfentry call, and the rest of the prologue
to follow afterwards. On x86, we don't need any "pre-prologue".
Persumably the corresponding opcodes have different sizes. This nicely
demonstrates my point -- if this one-gcc-option-to-rule-them-all would
exist, it needs to be generic enough to describe these kinds of
constraints (who knows what other restrictions will pop up when exploring
other, more exotic, architectures later).
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists