[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220328202131.jis7swqswm7chn6k@treble>
Date: Mon, 28 Mar 2022 13:21:31 -0700
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
"aik@...abs.ru" <aik@...abs.ru>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"naveen.n.rao@...ux.vnet.ibm.com" <naveen.n.rao@...ux.vnet.ibm.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Sathvika Vasireddy <sv@...ux.ibm.com>,
Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>, ardb@...nel.org
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions
On Mon, Mar 28, 2022 at 10:14:38PM +0200, Peter Zijlstra wrote:
> > FWIW, there have been some objtool patches for arm64 stack validation,
> > but the arm64 maintainers have been hesitant to get on board with
> > objtool, as it brings a certain maintenance burden. Especially for the
> > full stack validation and ORC unwinder. But if you only want inline
> > static calls and/or mcount then it'd probably be much easier to
> > maintain.
>
> IIRC the major stumbling block for arm64 is the whole jump-table thing.
> Either they need to rely on compiler plugins to provide objtool that
> data (yuck, since we support at least 2 different compilers), disable
> jump-tables (yuck, for that limits code-gen just to please a tool) or
> use DWARF (yuck, because build times).
Well yeah, that was indeed the main technical issue but I seem to
remember some arm64 maintainers not really being sold on the value of
objtool regardless.
> There was a little talk about an impromptu 'abi' to communicate
> jump-table details to objtool without going full on DWARF, but that
> seems to have hit a dead end again.
Probably my fault, not enough hours in the day...
--
Josh
Powered by blists - more mailing lists