Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC][PATCH 03/36] objtool: Enable compilation of objtool for all
 architectures
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Matt Helsley <mhelsley@vmware.com>, linux-kernel@vger.kernel.org,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Miroslav Benes <mbenes@suse.cz>
References: <cover.1586468801.git.mhelsley@vmware.com>
 <a96d42818c7e8f2a8bd2e151b8c220193f4ae986.1586468801.git.mhelsley@vmware.com>
 <e8a52162-dd38-6092-7217-cc5c088abadc@redhat.com>
 <20200414094121.73f5c82a@gandalf.local.home>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <59db4518-2450-e6a3-5a69-e65b86c39489@redhat.com>
Date:   Tue, 14 Apr 2020 15:01:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200414094121.73f5c82a@gandalf.local.home>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 4/14/20 2:41 PM, Steven Rostedt wrote:
> On Tue, 14 Apr 2020 08:39:23 +0100
> Julien Thierry <jthierry@redhat.com> wrote:
> 
>> My concern with this it that most of the structures and code in arch.h
>> and check.c can/should be reused across architectures. So, when
>> providing support for a new architecutre, the first thing that will be
>> needed is to move those back under tools/objtool whithout disturbing the
>> arches that don't yet provide support for "check" subcommand.
> 
> Are all the enums and structs in arch.h non-arch specific?

While some definitions are very x86 specific (in particular PUSH/POP 
related definition), most other other things have similar concept in 
other architectures.

And the "non-generic" definition here do not necessarily interfere with 
other architectures. E.g. if the instruction decoder never produces 
INSN_PUSH or INSN_POP, the corresponding branches in the validation code 
will simply not be taken.

> 
> Or would they need to be split?
> 

So far, for the arm64 work, I've left all those definitions where they 
are. In the future, some cleanup could encourage to split for some "arch 
specific" and "non-arch specific" instruction/stack-ops types, but this 
is not a hard requirement for introducing new architechtures. And I'd 
rather encourage to have complex arch specific instructions be divided 
into several simpler instructions (e.g. PUSH is just sub stack pointer + 
memory access) that could be reused for other architectures, as long as 
that is possible of course.


>>
>> So, if it is decided that recordmcount should be an objtool subcommand,
>> the code itself should probably stay under tools/objtool and then have
>> different compilation configurations for objtool depending on the
>> architecture (e.g. HAVE_OBJTOOL_CHECK, HAVE_OBJTOOL_ORC) or something of
>> the sort.
> 
> That could work.
> 
> -- Steve
> 

-- 
Julien Thierry