Re: [RFC 1/6] objtool: Refactor code to make it more suitable for multiple architecture support

[Raphael Gault]

On 4/23/19 9:13 PM, Josh Poimboeuf wrote:
> On Tue, Apr 09, 2019 at 02:52:38PM +0100, Raphael Gault wrote:
>> The jump destination and relocation offset used previously are only reliable
>> on x86_64 architecture. We abstract these computations by calling arch-dependant
>
> "dependent"
>
>> implementation.
>>
>> The control flow information and register macro definitions were based on
>> the x86_64 architecture but should be abstract so that each architecture
>> can define the correct values for the registers, especially the registers
>> related to the stack frame (Frame Pointer, Stack Pointer and possibly
>> Return Address).
>>
>> The ORC unwinder is only supported on x86 at the moment and should thus be
>> in the x86 architecture code. In order not to break the whole structure in
>> case another architecture decides to support the ORC unwinder via objtool
>> we choose to let the implementation be done in the architecture dependant
>> code.
>
> It's good practice to put each logical change into a separate patch.
> That will also make the patches easier to review.
>

Indeed this will be better.

> For example, each of the above three paragraphs should be a separate
> commit.
>
> Also it's a good idea to run the patches through checkpatch.pl (though
> its warnings should be taken with a grain of salt).
>

Yes, I realised after the comment from Peter that I needed to correct
quite a few things, thank you.

>> Signed-off-by: Raphael Gault <raphael.gault@xxxxxxx>
>> ---
>>   tools/objtool/Build                           |   1 -
>>   tools/objtool/arch.h                          |   9 ++
>>   tools/objtool/arch/x86/Build                  |   1 +
>>   tools/objtool/arch/x86/decode.c               | 106 ++++++++++++++++
>>   tools/objtool/arch/x86/include/arch_special.h |  35 ++++++
>>   tools/objtool/{ => arch/x86/include}/cfi.h    |   0
>>   tools/objtool/{ => arch/x86}/orc_gen.c        |  10 +-
>>   tools/objtool/check.c                         | 114 ++----------------
>>   tools/objtool/check.h                         |   1 +
>>   tools/objtool/orc.h                           |   4 +-
>>   tools/objtool/special.c                       |  18 +--
>>   11 files changed, 173 insertions(+), 126 deletions(-)
>>   create mode 100644 tools/objtool/arch/x86/include/arch_special.h
>>   rename tools/objtool/{ => arch/x86/include}/cfi.h (100%)
>>   rename tools/objtool/{ => arch/x86}/orc_gen.c (96%)
>>
>> diff --git a/tools/objtool/Build b/tools/objtool/Build
>> index 749becdf5b90..ec925d49565a 100644
>> --- a/tools/objtool/Build
>> +++ b/tools/objtool/Build
>> @@ -2,7 +2,6 @@ objtool-y += arch/$(SRCARCH)/
>>   objtool-y += builtin-check.o
>>   objtool-y += builtin-orc.o
>>   objtool-y += check.o
>> -objtool-y += orc_gen.o
>
> I'm not sure whether moving ORC out to the arch-specific code is the
> best option.  I expect a lot of the ORC code to be generic.  But this
> might be ok for now, until we get another ORC implementation.
>
> Another possibility would be to make weak versions of the orc functions
> somewhere (check.c?) and only compile the generic orc_gen.c on arches
> which support it.  Then we could abstract out the arch-specific ORC bits
> later.
>
>>   objtool-y += orc_dump.o
>
> orc_dump.o doesn't need to be built on arm64.  The "orc dump" option
> should fail accordingly.
>
>>   objtool-y += elf.o
>>   objtool-y += special.o
>> diff --git a/tools/objtool/arch.h b/tools/objtool/arch.h
>> index b0d7dc3d71b5..0eff166ca613 100644
>> --- a/tools/objtool/arch.h
>> +++ b/tools/objtool/arch.h
>> @@ -22,6 +22,7 @@
>>   #include <linux/list.h>
>>   #include "elf.h"
>>   #include "cfi.h"
>> +#include "orc.h"
>>
>>   #define INSN_JUMP_CONDITIONAL1
>>   #define INSN_JUMP_UNCONDITIONAL2
>> @@ -70,6 +71,8 @@ struct stack_op {
>>   struct op_src src;
>>   };
>>
>> +struct instruction;
>> +
>>   void arch_initial_func_cfi_state(struct cfi_state *state);
>>
>>   int arch_decode_instruction(struct elf *elf, struct section *sec,
>> @@ -79,4 +82,10 @@ int arch_decode_instruction(struct elf *elf, struct section *sec,
>>
>>   bool arch_callee_saved_reg(unsigned char reg);
>>
>> +int arch_orc_read_unwind_hints(struct objtool_file *file);
>> +
>> +unsigned long arch_compute_jump_destination(struct instruction *insn);
>> +
>> +unsigned long arch_compute_rela_sym_offset(int addend);
>
> arch_dest_rela_addend_offset() might be a more descriptive name.  Also
> it might be simpler to just make it an arch-specific macro which is 0 on
> arm64 and 4 on x86.
>
> "compute" is implied, it can probably be removed from the names to make
> them a little more concise.
>

I am more in favor of the functions, I have to admit I don't know which
is really better but in any event I will rename them.

>> +
>>   #endif /* _ARCH_H */
>> diff --git a/tools/objtool/arch/x86/Build b/tools/objtool/arch/x86/Build
>> index b998412c017d..74015be53ef0 100644
>> --- a/tools/objtool/arch/x86/Build
>> +++ b/tools/objtool/arch/x86/Build
>> @@ -1,4 +1,5 @@
>>   objtool-y += decode.o
>> +objtool-y += orc_gen.o
>>
>>   inat_tables_script = arch/x86/tools/gen-insn-attr-x86.awk
>>   inat_tables_maps = arch/x86/lib/x86-opcode-map.txt
>> diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
>> index 540a209b78ab..1af7b4996307 100644
>> --- a/tools/objtool/arch/x86/decode.c
>> +++ b/tools/objtool/arch/x86/decode.c
>> @@ -23,6 +23,8 @@
>>   #include "lib/inat.c"
>>   #include "lib/insn.c"
>>
>> +
>> +#include "../../check.h"
>>   #include "../../elf.h"
>>   #include "../../arch.h"
>>   #include "../../warn.h"
>> @@ -78,6 +80,105 @@ bool arch_callee_saved_reg(unsigned char reg)
>>   }
>>   }
>>
>> +unsigned long arch_compute_rela_sym_offset(int addend)
>> +{
>> +return addend + 4;
>> +}
>> +
>> +int arch_orc_read_unwind_hints(struct objtool_file *file)
>
> I think this function would be better suited for orc_gen.c (which could
> be renamed to just orc.c).
>

That is indeed true. I did that for the arm64 side so for consistency it
should be the same here.

>> diff --git a/tools/objtool/arch/x86/include/arch_special.h b/tools/objtool/arch/x86/include/arch_special.h
>> new file mode 100644
>> index 000000000000..bd91b1096359
>> --- /dev/null
>> +++ b/tools/objtool/arch/x86/include/arch_special.h
>> @@ -0,0 +1,35 @@
>> +/*
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>
> This needs the standard header macro guards, e.g.
>
> #ifndef _X86_ARCH_SPECIAL_H
> #define _X86_ARCH_SPECIAL_H
>

I will correct this! Thank you.
>> +
>> +#define EX_ENTRY_SIZE12
>> +#define EX_ORIG_OFFSET0
>> +#define EX_NEW_OFFSET4
>> +
>> +#define JUMP_ENTRY_SIZE16
>> +#define JUMP_ORIG_OFFSET0
>> +#define JUMP_NEW_OFFSET4
>> +
>> +#define ALT_ENTRY_SIZE13
>> +#define ALT_ORIG_OFFSET0
>> +#define ALT_NEW_OFFSET4
>> +#define ALT_FEATURE_OFFSET8
>> +#define ALT_ORIG_LEN_OFFSET10
>> +#define ALT_NEW_LEN_OFFSET11
>> +
>> +#define IGNORE_SHF_EXEC_FLAG0
>> +
>> +#define JUMP_DYNAMIC_IS_SWITCH_TABLE0
>
> These flags should be added with the commit which actually uses them.
>
> Also "arch_special.h" is specific to special section parsing, so I'm
> thinking these two macros don't really belong here.  Or maybe the header
> file could be renamed to something more generic.
>

My approach was indeed wrong. In the next version I'll get rid of those
macros which are inelegant and unrelated to x86.

Thanks,

--
Raphael Gault
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.