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

[Julien Thierry]

On 4/14/20 2:41 PM, Steven Rostedt wrote:
> On Tue, 14 Apr 2020 08:39:23 +0100
> Julien Thierry <jthierry@xxxxxxxxxx> 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