| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Reapply "objtool/LoongArch: Enable objtool to be built" This reverts commit d390ea1bb458f71919b8d53bee92b9322d84ad9f. | 1 年前 | |
Reapply "objtool/LoongArch: Enable orc to be built" This reverts commit 450777d1049a6ac767a1ef2d3a27b8da76f9eed6. | 1 年前 | |
objtool/LoongArch: Mark special atomic instruction as INSN_BUG type mainline inclusion from mainline-v6.17-rc7 category: bugfix When compiling with LLVM and CONFIG_RUST is set, there exists the following objtool warning: rust/compiler_builtins.o: warning: objtool: __rust__unordsf2(): unexpected end of section .text.unlikely. objdump shows that the end of section .text.unlikely is an atomic instruction: amswap.w $zero, $ra, $zero According to the LoongArch Reference Manual, if the amswap.w atomic memory access instruction has the same register number as rd and rj, the execution will trigger an Instruction Non-defined Exception, so mark the above instruction as INSN_BUG type to fix the warning. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> [It also fixes objtool other warning such as "warning: objtool: __checkpoint_and_complete_reqs() falls through to next function issue_checkpoint_thread()"] (cherry picked from commit 539d7344d4feaea37e05863e9aa86bd31f28e46f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 4 个月前 | |
Reapply "objtool/LoongArch: Enable orc to be built" This reverts commit 450777d1049a6ac767a1ef2d3a27b8da76f9eed6. | 1 年前 | |
objtool/LoongArch: Add support for goto table The objtool program need 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 type on the jump instruction and directly points to the table. But on LoongArch, the relocation is on another kind of instruction prior to the jump instruction, and also with scheduling it is not very 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" and a Clang patch "[LoongArch] Add options for annotate tablejump" have been merged into the upstream mainline, it can parse 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@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> | 1 年前 |