Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 28 Mar 2022 12:59:20 -0700
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Christophe Leroy <christophe.leroy@csgroup.eu>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        "aik@ozlabs.ru" <aik@ozlabs.ru>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        "naveen.n.rao@linux.vnet.ibm.com" <naveen.n.rao@linux.vnet.ibm.com>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        Sathvika Vasireddy <sv@linux.ibm.com>
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions
Message-ID: <20220328195920.dqlfra3lcardko6r@treble>
References: <20220318105140.43914-1-sv@linux.ibm.com>
 <20220318105140.43914-4-sv@linux.ibm.com>
 <YjR6kHq4c/rjCTpr@hirez.programming.kicks-ass.net>
 <0b55f122-4760-c1ba-840a-0911cefec2ad@csgroup.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <0b55f122-4760-c1ba-840a-0911cefec2ad@csgroup.eu>
Precedence: bulk

On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
> Second point is the endianess and 32/64 selection, especially when 
> crossbuilding. There is already some stuff regarding endianess based on 
> bswap_if_needed() but that's based on constant selection at build time 
> and I couldn't find an easy way to set it conditionaly based on the 
> target being built.
>
> Regarding 32/64 selection, there is almost nothing, it's based on using 
> type 'long' which means that at the time being the target and the build 
> platform must both be 32 bits or 64 bits.
> 
> For both cases (endianess and 32/64) I think the solution should 
> probably be to start with the fileformat of the object file being 
> reworked by objtool.

Do we really need to detect the endianness/bitness at runtime?  Objtool
is built with the kernel, why not just build-in the same target
assumptions as the kernel itself?

> What are current works in progress on objtool ? Should I wait Josh's 
> changes before starting looking at all this ? Should I wait for anything 
> else ?

I'm not making any major changes to the code, just shuffling things
around to make the interface more modular.  I hope to have something
soon (this week).  Peter recently added a big feature (Intel IBT) which
is already in -next.

Contributions are welcome, with the understanding that you'll help
maintain it ;-)

Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation.  I'm not sure what ever became of
that.

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.

-- 
Josh