Re: [RFC][PATCH 03/36] objtool: Enable compilation of objtool for all architectures

[Julien Thierry <jthierry@redhat.com>]

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