This RFC version is based on Linux 6.10-rc7, there are no detailed
commit messages for each patch for now and the code are relatively
clear and simple.

This series is tested with the latest upstream gcc applied with patch
"LoongArch: Add support to annotate tablejump" [1] which adds a new
section discard.tablejump_annotate to record the jump info, it makes
life much easier, special thanks to Ruoyao.

I will address all the review comments and update the commit messages
after the merge window.

[1] https://inbox.sourceware.org/gcc-patches/20240711114415.4420-1-xry111@xry111.site/

Tiezhu Yang (4):
  objtool: Check local label in find_jump_table()
  objtool: Check various types in add_jump_table()
  objtool/LoongArch: Add support for jump table
  LoongArch: Remove -fno-jump-tables for objtool

 arch/loongarch/Kconfig                 |  8 +++-
 arch/loongarch/Makefile                |  6 +--
 tools/objtool/arch/loongarch/special.c | 54 +++++++++++++++++++++++++-
 tools/objtool/check.c                  | 36 +++++++++++++++--
 4 files changed, 94 insertions(+), 10 deletions(-)

-- 
2.42.0

Are we always avoid our problems?

1, When text section not support "R_LARCH_32_PCREL", update compiler
    to add AS_HAS_THIN_ADD_SUB.
2, When not support jump-table, use "-fno-jump-tables" to avoid it,
    (and now update compiler to add CC_HAS_ANNOTATE_TABLEJUMP).
3, When not support relax, use "-mno-relax" to avoid it.
4, When some where in asm can be backtraced but generate warning,
    use STACK_FRAME_NON_STANDARD to avoid it.
5, When the goto-table cannot be handled (I guess the Ruoyao's
    patch cannot handle goto table), use CONFIG_BPF_JIT_ALWAYS_ON
    to avoid compile ___bpf_prog_run.
6, And other $fp warnings not be solved in clang. Do we only care gcc?

So how to do in the future if compilers have other changed? Do we
need update compilers (both gcc and clang) again and again? Why
not just update objtool codes to solves these problems? As many
RISC arch not support directly find jump table, can we support
more generic ways to find it?


On 2024-07-12 17:15, Tiezhu Yang wrote:
> This RFC version is based on Linux 6.10-rc7, there are no detailed
> commit messages for each patch for now and the code are relatively
> clear and simple.
>
> This series is tested with the latest upstream gcc applied with patch
> "LoongArch: Add support to annotate tablejump" [1] which adds a new
> section discard.tablejump_annotate to record the jump info, it makes
> life much easier, special thanks to Ruoyao.
>
> I will address all the review comments and update the commit messages
> after the merge window.
>
> [1] https://inbox.sourceware.org/gcc-patches/20240711114415.4420-1-xry111@xry111.site/
>
> Tiezhu Yang (4):
>    objtool: Check local label in find_jump_table()
>    objtool: Check various types in add_jump_table()
>    objtool/LoongArch: Add support for jump table
>    LoongArch: Remove -fno-jump-tables for objtool
>
>   arch/loongarch/Kconfig                 |  8 +++-
>   arch/loongarch/Makefile                |  6 +--
>   tools/objtool/arch/loongarch/special.c | 54 +++++++++++++++++++++++++-
>   tools/objtool/check.c                  | 36 +++++++++++++++--
>   4 files changed, 94 insertions(+), 10 deletions(-)
>

On 07/12/2024 06:19 PM, Jinyang He wrote:
> Are we always avoid our problems?
>
> 1, When text section not support "R_LARCH_32_PCREL", update compiler
>    to add AS_HAS_THIN_ADD_SUB.
> 2, When not support jump-table, use "-fno-jump-tables" to avoid it,
>    (and now update compiler to add CC_HAS_ANNOTATE_TABLEJUMP).
> 3, When not support relax, use "-mno-relax" to avoid it.
> 4, When some where in asm can be backtraced but generate warning,
>    use STACK_FRAME_NON_STANDARD to avoid it.
> 5, When the goto-table cannot be handled (I guess the Ruoyao's
>    patch cannot handle goto table), use CONFIG_BPF_JIT_ALWAYS_ON
>    to avoid compile ___bpf_prog_run.
> 6, And other $fp warnings not be solved in clang. Do we only care gcc?
>
> So how to do in the future if compilers have other changed? Do we
> need update compilers (both gcc and clang) again and again? Why
> not just update objtool codes to solves these problems? As many
> RISC arch not support directly find jump table, can we support
> more generic ways to find it?

This is a choose and balance. In principle, I want to make the kernel
code clear and simple to enhance the readability and maintainability,
I do not want to modify too much architecture independent code of the
objtool framework, I just want to implement the architecture specific
function.

As the gcc patch "LoongArch: Add support to annotate tablejump" said,
the objtool program needs to analysis the control flow of each .o file
generated by compiler toolchain, if a jump table is used, objtool has
to correlate the jump instruction with the table, on x86 it's simple:
a relocation entry natrually correlates them because one instruction is
used for table-based jump, but on an RISC machine objtool would have to
reconstruct the data flow if it must find out the correlation on its own,
so emit an additional section to store the correlation info as pairs of
addresses, each pair contains the address of a jump instruction (jr) and
the address of the jump table. This is very trivial to implement in GCC.

For jump table support of objtool on LoongArch, it makes life much easier
with the gcc changes. As far as I can see, the remain issues (goto table
in ___bpf_prog_run() and jump table in assemble code) are only related
with kernel and can be solved with kernel changes.

Thanks,
Tiezhu