lkml.org 
[lkml]   [2020]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 03/36] objtool: Enable compilation of objtool for all architectures
From
Date


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

\
 
 \ /
  Last update: 2020-04-14 16:02    [W:0.070 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site