objtool/LoongArch: Get table size correctly if LTO is enabledWhen compiling with LLVM and CONFIG_LTO_CLANG is set, there exist manyobjtool warnings "sibling call from callable instruction with mod
objtool/LoongArch: Get table size correctly if LTO is enabledWhen compiling with LLVM and CONFIG_LTO_CLANG is set, there exist manyobjtool warnings "sibling call from callable instruction with modifiedstack frame".For this special case, the related object file shows that there is nogenerated relocation section '.rela.discard.tablejump_annotate' for thetable jump instruction jirl, thus objtool can not know that what is theactual destination address.It needs to do something on the LLVM side to make sure that there is therelocation section '.rela.discard.tablejump_annotate' if LTO is enabled,but in order to maintain compatibility for the current LLVM compiler,this can be done in the kernel Makefile for now. Ensure it is aware oflinker with LTO, '--loongarch-annotate-tablejump' needs to be passed via'-mllvm' to ld.lld.Before doing the above changes, it should handle the special case of therelocation section '.rela.discard.tablejump_annotate' to get the correcttable size first, otherwise there are many objtool warnings and errorsif LTO is enabled.There are many different rodata for each function if LTO is enabled, itis necessary to enhance get_rodata_table_size_by_table_annotate().Fixes: b95f852d3af2 ("objtool/LoongArch: Add support for switch table")Closes: https://lore.kernel.org/loongarch/20250731175655.GA1455142@ax162/Reported-by: Nathan Chancellor <nathan@kernel.org>Tested-by: Nathan Chancellor <nathan@kernel.org>Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
show more ...
objtool: Change "warning:" to "error: " for fatal errorsThis is similar to GCC's behavior and makes it more obvious why thebuild failed.Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>Signed
objtool: Change "warning:" to "error: " for fatal errorsThis is similar to GCC's behavior and makes it more obvious why thebuild failed.Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>Signed-off-by: Ingo Molnar <mingo@kernel.org>Cc: Linus Torvalds <torvalds@linux-foundation.org>Link: https://lore.kernel.org/r/0ea76f4b0e7a370711ed9f75fd0792bb5979c2bf.1743481539.git.jpoimboe@kernel.org
objtool/LoongArch: Add support for goto tableThe objtool program need to analysis the control flow of each object filegenerated by compiler toolchain, it needs to know all the locations thata bra
objtool/LoongArch: Add support for goto tableThe objtool program need to analysis the control flow of each object filegenerated by compiler toolchain, it needs to know all the locations thata branch instruction may jump into, if a jump table is used, objtool hasto 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 pointsto the table. But on LoongArch, the relocation is on another kind ofinstruction prior to the jump instruction, and also with scheduling itis not very easy to tell the offset of that instruction from the jumpinstruction. Furthermore, because LoongArch has -fsection-anchors (oftenenabled at -O1 or above) the relocation may actually points to a sectionanchor instead of the table itself.For the jump table of switch cases, a GCC patch "LoongArch: Add supportto annotate tablejump" and a Clang patch "[LoongArch] Add options forannotate tablejump" have been merged into the upstream mainline, it canparse the additional section ".discard.tablejump_annotate" which storesthe jump info as pairs of addresses, each pair contains the address ofjump instruction and the address of jump table.For the jump table of computed gotos, it is indeed not easy to implementin the compiler, especially if there is more than one computed goto in afunction such as ___bpf_prog_run(). objdump kernel/bpf/core.o shows thatthere are many table jump instructions in ___bpf_prog_run(), but there areno relocations on the table jump instructions and to the table directly onLoongArch.Without the help of compiler, in order to figure out the address of gototable for the special case of ___bpf_prog_run(), since the instructionsequence is relatively single and stable, it makes sense to add a helperfind_reloc_of_rodata_c_jump_table() to find the relocation which pointsto the section ".rodata..c_jump_table".If find_reloc_by_table_annotate() failed, it means there is no relocationinfo of switch table address in ".rela.discard.tablejump_annotate", thenobjtool 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>Link: https://lore.kernel.org/r/20250211115016.26913-6-yangtiezhu@loongson.cnAcked-by: Huacai Chen <chenhuacai@loongson.cn>Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
objtool/LoongArch: Add support for switch tableThe objtool program need to analysis the control flow of each object filegenerated by compiler toolchain, it needs to know all the locations thata b
objtool/LoongArch: Add support for switch tableThe objtool program need to analysis the control flow of each object filegenerated by compiler toolchain, it needs to know all the locations thata branch instruction may jump into, if a jump table is used, objtool hasto 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 pointsto the table. But on LoongArch, the relocation is on another kind ofinstruction prior to the jump instruction, and also with scheduling itis not very easy to tell the offset of that instruction from the jumpinstruction. Furthermore, because LoongArch has -fsection-anchors (oftenenabled at -O1 or above) the relocation may actually points to a sectionanchor instead of the table itself.The good news is that after continuous analysis and discussion, at lasta GCC patch "LoongArch: Add support to annotate tablejump" and a Clangpatch "[LoongArch] Add options for annotate tablejump" have been mergedinto the upstream mainline, the compiler changes make life much easierfor switch table support of objtool on LoongArch.By now, there is an additional section ".discard.tablejump_annotate" tostore the jump info as pairs of addresses, each pair contains the addressof jump instruction and the address of jump table.In order to find switch table, it is easy to parse the relocation section".rela.discard.tablejump_annotate" to get table_sec and table_offset, therest process is somehow like x86.Additionally, it needs to get each table size. When compiling on LoongArch,there are unsorted table offsets of rodata if there exist many jump tables,it will get the wrong table end and find the wrong table jump destinationinstructions in add_jump_table().Sort the rodata table offset by parsing ".rela.discard.tablejump_annotate"and then get each table size of rodata corresponded with each table jumpinstruction, it is used to check the table end and will break the processwhen parsing ".rela.rodata" to avoid getting the wrong jump destinationinstructions.Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0ee028f55640Link: https://github.com/llvm/llvm-project/commit/4c2c17756739Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Link: https://lore.kernel.org/r/20250211115016.26913-5-yangtiezhu@loongson.cnAcked-by: Huacai Chen <chenhuacai@loongson.cn>Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Handle PC relative relocation typeFor the most part, an absolute relocation type is used for rodata.In the case of STT_SECTION, reloc->sym->offset is always zero, forthe other symbol typ
objtool: Handle PC relative relocation typeFor the most part, an absolute relocation type is used for rodata.In the case of STT_SECTION, reloc->sym->offset is always zero, forthe other symbol types, reloc_addend(reloc) is always zero, thus itcan use a simple statement "reloc->sym->offset + reloc_addend(reloc)"to obtain the symbol offset for various symbol types.When compiling on LoongArch, there exist PC relative relocation typesfor rodata, it needs to calculate the symbol offset with "S + A - PC"according to the spec of "ELF for the LoongArch Architecture".If there is only one jump table in the rodata, the "PC" is the entryaddress which is equal with the value of reloc_offset(reloc), at thistime, reloc_offset(table) is 0.If there are many jump tables in the rodata, the "PC" is the offsetof the jump table's base address which is equal with the value ofreloc_offset(reloc) - reloc_offset(table).So for LoongArch, if the relocation type is PC relative, it can use astatement "reloc_offset(reloc) - reloc_offset(table)" to get the "PC"value when calculating the symbol offset with "S + A - PC" for one ormany jump tables in the rodata.Add an arch-specific function arch_jump_table_sym_offset() to assignthe symbol offset, for the most part that is an absolute relocation,the default value is "reloc->sym->offset + reloc_addend(reloc)" inthe weak definition, it can be overridden by each architecture thathas different requirements.Link: https://github.com/loongson/la-abi-specs/blob/release/laelf.adocSigned-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Link: https://lore.kernel.org/r/20250211115016.26913-4-yangtiezhu@loongson.cnAcked-by: Huacai Chen <chenhuacai@loongson.cn>Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Handle different entry size of rodataIn the most cases, the entry size of rodata is 8 bytes because therelocation type is 64 bit. There are also 32 bit relocation types,the entry size of
objtool: Handle different entry size of rodataIn the most cases, the entry size of rodata is 8 bytes because therelocation type is 64 bit. There are also 32 bit relocation types,the entry size of rodata should be 4 bytes in this case.Add an arch-specific function arch_reloc_size() to assign the entrysize of rodata for x86, powerpc and LoongArch.Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Link: https://lore.kernel.org/r/20250211115016.26913-3-yangtiezhu@loongson.cnAcked-by: Huacai Chen <chenhuacai@loongson.cn>Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Allow arch code to discover jump table sizeIn preparation for adding support for annotated jump tables, whereELF relocations and symbols are used to describe the locations of jumptables
objtool: Allow arch code to discover jump table sizeIn preparation for adding support for annotated jump tables, whereELF relocations and symbols are used to describe the locations of jumptables in the executable, refactor the jump table discovery logic so thetable size can be returned from arch_find_switch_table().Signed-off-by: Ard Biesheuvel <ardb@kernel.org>Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>Link: https://lkml.kernel.org/r/20241011170847.334429-12-ardb+git@google.com
objtool: Handle frame pointer related instructionsAfter commit a0f7085f6a63 ("LoongArch: Add RANDOMIZE_KSTACK_OFFSETsupport"), there are three new instructions "addi.d $fp, $sp, 32","sub.d $sp, $
objtool: Handle frame pointer related instructionsAfter commit a0f7085f6a63 ("LoongArch: Add RANDOMIZE_KSTACK_OFFSETsupport"), there are three new instructions "addi.d $fp, $sp, 32","sub.d $sp, $sp, $t0" and "addi.d $sp, $fp, -32" for the secondarystack in do_syscall(), then there is a objtool warning "return withmodified stack frame" and no handle_syscall() which is the previousframe of do_syscall() in the call trace when executing the command"echo l > /proc/sysrq-trigger".objdump shows something like this:0000000000000000 <do_syscall>: 0: 02ff8063 addi.d $sp, $sp, -32 4: 29c04076 st.d $fp, $sp, 16 8: 29c02077 st.d $s0, $sp, 8 c: 29c06061 st.d $ra, $sp, 24 10: 02c08076 addi.d $fp, $sp, 32 ... 74: 0011b063 sub.d $sp, $sp, $t0 ... a8: 4c000181 jirl $ra, $t0, 0 ... dc: 02ff82c3 addi.d $sp, $fp, -32 e0: 28c06061 ld.d $ra, $sp, 24 e4: 28c04076 ld.d $fp, $sp, 16 e8: 28c02077 ld.d $s0, $sp, 8 ec: 02c08063 addi.d $sp, $sp, 32 f0: 4c000020 jirl $zero, $ra, 0The instruction "sub.d $sp, $sp, $t0" changes the stack bottom and thenew stack size is a random value, in order to find the return address ofdo_syscall() which is stored in the original stack frame after executing"jirl $ra, $t0, 0", it should use fp which points to the original stacktop.At the beginning, the thought is tended to decode the secondary stackinstruction "sub.d $sp, $sp, $t0" and set it as a label, then check thislabel for the two frame pointer instructions to change the cfa base andcfa offset during the period of secondary stack in update_cfi_state().This is valid for GCC but invalid for Clang due to there are differentsecondary stack instructions for ClangBuiltLinux on LoongArch, somethinglike this:0000000000000000 <do_syscall>: ... 88: 00119064 sub.d $a0, $sp, $a0 8c: 00150083 or $sp, $a0, $zero ...Actually, it equals to a single instruction "sub.d $sp, $sp, $a0", butthere is no proper condition to check it as a label like GCC, and so thebeginning thought is not a good way.Essentially, there are two special frame pointer instructions which are"addi.d $fp, $sp, imm" and "addi.d $sp, $fp, imm", the first one pointsfp to the original stack top and the second one restores the originalstack bottom from fp.Based on the above analysis, in order to avoid adding an arch-specificupdate_cfi_state(), we just add a member "frame_pointer" in the "structsymbol" as a label to avoid affecting the current normal case, then setit as true only if there is "addi.d $sp, $fp, imm". The last is to checkthis label for the two frame pointer instructions to change the cfa baseand cfa offset in update_cfi_state().Tested with the following two configs:(1) CONFIG_RANDOMIZE_KSTACK_OFFSET=y && CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=n(2) CONFIG_RANDOMIZE_KSTACK_OFFSET=y && CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=yBy the way, there is no effect for x86 with this patch, tested on thex86 machine with Fedora 40 system.Cc: stable@vger.kernel.org # 6.9+Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
objtool/LoongArch: Enable orc to be builtImplement arch-specific init_orc_entry(), write_orc_entry(), reg_name(),orc_type_name(), print_reg() and orc_print_dump(), then set BUILD_ORC asy to build
objtool/LoongArch: Enable orc to be builtImplement arch-specific init_orc_entry(), write_orc_entry(), reg_name(),orc_type_name(), print_reg() and orc_print_dump(), then set BUILD_ORC asy to build the orc related files.Co-developed-by: Jinyang He <hejinyang@loongson.cn>Signed-off-by: Jinyang He <hejinyang@loongson.cn>Co-developed-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
objtool/LoongArch: Implement instruction decoderOnly copy the minimal definitions of instruction opcodes and formatsin inst.h from arch/loongarch to tools/arch/loongarch, and also copythe definit
objtool/LoongArch: Implement instruction decoderOnly copy the minimal definitions of instruction opcodes and formatsin inst.h from arch/loongarch to tools/arch/loongarch, and also copythe definition of sign_extend64() to tools/include/linux/bitops.h todecode the following kinds of instructions:(1) stack pointer related instructionsaddi.d, ld.d, st.d, ldptr.d and stptr.d(2) branch and jump related instructionsbeq, bne, blt, bge, bltu, bgeu, beqz, bnez, bceqz, bcnez, b, bl and jirl(3) other instructionsbreak, nop and ertnSee more info about instructions in LoongArch Reference Manual:https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.htmlCo-developed-by: Jinyang He <hejinyang@loongson.cn>Signed-off-by: Jinyang He <hejinyang@loongson.cn>Co-developed-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
objtool/LoongArch: Enable objtool to be builtAdd the minimal changes to enable objtool build on LoongArch,most of the functions are stubs to only fix the build errorswhen make -C tools/objtool.
objtool/LoongArch: Enable objtool to be builtAdd the minimal changes to enable objtool build on LoongArch,most of the functions are stubs to only fix the build errorswhen make -C tools/objtool.This is similar with commit e52ec98c5ab1 ("objtool/powerpc:Enable objtool to be built on ppc").Co-developed-by: Jinyang He <hejinyang@loongson.cn>Signed-off-by: Jinyang He <hejinyang@loongson.cn>Co-developed-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Youling Tang <tangyouling@loongson.cn>Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>