[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241105123906.26072-5-yangtiezhu@loongson.cn>
Date: Tue, 5 Nov 2024 20:39:05 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: [PATCH v2 4/5] objtool/LoongArch: Add support for goto table
The objtool program needs to analysis the control flow of each object file
generated by compiler toolchain, it needs to know all the locations that a
branch instruction may jump into, if a jump table is used, objtool has to
correlate the jump instruction with the table.
On x86 which is the only port supported by objtool before LoongArch, there
is a relocation on the jump instruction and to the table directly. But on
LoongArch, the relocation is on some kind of instruction prior to the jump
instruction, and also with scheduling it is not easy to tell the offset of
that instruction from the jump instruction. Furthermore, because LoongArch
has -fsection-anchors (often enabled at -O1 or above) the relocation may
actually points to a section anchor instead of the table itself.
For the jump table of switch cases, a GCC patch "LoongArch: Add support to
annotate tablejump" has been merged into the upstream mainline, it makes
life much easier with the additional section ".discard.tablejump_annotate"
which stores the jump info as pairs of addresses, each pair contains the
address of jump instruction and the address of jump table.
For the jump table of computed gotos, it is indeed not easy to implement
in the compiler, especially if there is more than one computed goto in a
function such as ___bpf_prog_run(). objdump kernel/bpf/core.o shows that
there are many table jump instructions in ___bpf_prog_run(), but there are
no relocations on the table jump instructions and to the table directly on
LoongArch.
Without the help of compiler, in order to figure out the address of goto
table for the special case of ___bpf_prog_run(), since the instruction
sequence is relatively single and stable, it makes sense to add a helper
find_reloc_of_rodata_c_jump_table() to find the relocation which points
to the section ".rodata..c_jump_table".
If find_reloc_by_table_annotate() failed, it means there is no relocation
info of switch table address in ".rela.discard.tablejump_annotate", then
objtool may find the relocation info of goto table ".rodata..c_jump_table"
with find_reloc_of_rodata_c_jump_table().
Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
---
tools/objtool/arch/loongarch/special.c | 28 ++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/tools/objtool/arch/loongarch/special.c b/tools/objtool/arch/loongarch/special.c
index 31e0f94e31e8..fe7413bcd98b 100644
--- a/tools/objtool/arch/loongarch/special.c
+++ b/tools/objtool/arch/loongarch/special.c
@@ -41,6 +41,27 @@ static struct reloc *find_reloc_by_table_annotate(struct objtool_file *file,
return NULL;
}
+static struct reloc *find_reloc_of_rodata_c_jump_table(struct section *sec,
+ unsigned long offset)
+{
+ struct section *rsec;
+ struct reloc *reloc;
+
+ rsec = sec->rsec;
+ if (!rsec)
+ return NULL;
+
+ for_each_reloc(rsec, reloc) {
+ if (reloc_offset(reloc) > offset)
+ break;
+
+ if (!strncmp(reloc->sym->sec->name, ".rodata..c_jump_table", 21))
+ return reloc;
+ }
+
+ return NULL;
+}
+
struct reloc *arch_find_switch_table(struct objtool_file *file,
struct instruction *insn)
{
@@ -50,8 +71,11 @@ struct reloc *arch_find_switch_table(struct objtool_file *file,
unsigned long table_offset;
annotate_reloc = find_reloc_by_table_annotate(file, insn);
- if (!annotate_reloc)
- return NULL;
+ if (!annotate_reloc) {
+ annotate_reloc = find_reloc_of_rodata_c_jump_table(insn->sec, insn->offset);
+ if (!annotate_reloc)
+ return NULL;
+ }
table_sec = annotate_reloc->sym->sec;
if (annotate_reloc->sym->type == STT_SECTION)
--
2.42.0
Powered by blists - more mailing lists