Messages in this thread | | | Subject | Re: [RFC][PATCH 03/36] objtool: Enable compilation of objtool for all architectures | From | Julien Thierry <> | Date | Tue, 14 Apr 2020 15:01:18 +0100 |
| |
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
| |