user/sven/linux.git/scripts/recordmcount.pl, branch v4.19.278

recordmcount.pl: fix typo in s390 mcount regex

2022-01-05T11:34:58Z

commit 4eb1782eaa9fa1c224ad1fa0d13a9f09c3ab2d80 upstream. Commit 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") added a new alternative mnemonic for the existing brcl instruction. This is required for the combination old gcc version (pre 9.0) and binutils since version 2.37. However at the same time this commit introduced a typo, replacing brcl with bcrl. As a result no mcount locations are detected anymore with old gcc versions (pre 9.0) and binutils before version 2.37. Fix this by using the correct mnemonic again. Reported-by: Miroslav Benes Cc: Jerome Marchand Cc: Fixes: 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") Link: https://lore.kernel.org/r/alpine.LSU.2.21.2112230949520.19849@pobox.suse.cz Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

recordmcount.pl: look for jgnop instruction as well as bcrl on s390

2021-12-22T08:19:00Z

commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream. On s390, recordmcount.pl is looking for "bcrl 0," instructions in the objdump -d outpout. However since binutils 2.37, objdump -d display "jgnop " for the same instruction. Update the mcount_regex so that it accepts both. Signed-off-by: Jerome Marchand Reviewed-by: Miroslav Benes Acked-by: Steven Rostedt (VMware) Cc: Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

nds32/ftrace: Fix Error: invalid operands (UND and UND sections) for `^'

2021-10-20T09:23:01Z

commit be358af1191b1b2fedebd8f3421cafdc8edacc7d upstream. I received a build failure for a new patch I'm working on the nds32 architecture, and when I went to test it, I couldn't get to my build error, because it failed to build with a bunch of: Error: invalid operands (*UND* and *UND* sections) for `^' issues with various files. Those files were temporary asm files that looked like: kernel/.tmp_mc_fork.s I decided to look deeper, and found that the "mc" portion of that name stood for "mcount", and was created by the recordmcount.pl script. One that I wrote over a decade ago. Once I knew the source of the problem, I was able to investigate it further. The way the recordmcount.pl script works (BTW, there's a C version that simply modifies the ELF object) is by doing an "objdump" on the object file. Looks for all the calls to "mcount", and creates an offset of those locations from some global variable it can use (usually a global function name, found with <.*>:). Creates a asm file that is a table of references to these locations, using the found variable/function. Compiles it and links it back into the original object file. This asm file is called ".tmp_mc_.s". The problem here is that the objdump produced by the nds32 object file, contains things that look like: 0000159a <.L3^B1>: 159a: c6 00 beqz38 $r6, 159a <.L3^B1> 159a: R_NDS32_9_PCREL_RELA .text+0x159e 159c: 84 d2 movi55 $r6, #-14 159e: 80 06 mov55 $r0, $r6 15a0: ec 3c addi10.sp #0x3c Where ".L3^B1 is somehow selected as the "global" variable to index off of. Then the assembly file that holds the mcount locations looks like this: .section __mcount_loc,"a",@progbits .align 2 .long .L3^B1 + -5522 .long .L3^B1 + -5384 .long .L3^B1 + -5270 .long .L3^B1 + -5098 .long .L3^B1 + -4970 .long .L3^B1 + -4758 .long .L3^B1 + -4122 [...] And when it is compiled back to an object to link to the original object, the compile fails on the "^" symbol. Simple solution for now, is to have the perl script ignore using function symbols that have an "^" in the name. Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Greentime Hu Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman

riscv: Workaround mcount name prior to clang-13

2021-05-22T08:59:49Z

[ Upstream commit 7ce04771503074a7de7f539cc43f5e1b385cb99b ] Prior to clang 13.0.0, the RISC-V name for the mcount symbol was "mcount", which differs from the GCC version of "_mcount", which results in the following errors: riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_level': main.c:(.text+0xe): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_start': main.c:(.text+0x4e): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_finish': main.c:(.text+0x92): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `.LBB32_28': main.c:(.text+0x30c): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `free_initmem': main.c:(.text+0x54c): undefined reference to `mcount' This has been corrected in https://reviews.llvm.org/D98881 but the minimum supported clang version is 10.0.1. To avoid build errors and to gain a working function tracer, adjust the name of the mcount symbol for older versions of clang in mount.S and recordmcount.pl. Link: https://github.com/ClangBuiltLinux/linux/issues/1331 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

scripts/recordmcount.pl: Fix RISC-V regex for clang

2021-05-22T08:59:49Z

[ Upstream commit 2f095504f4b9cf75856d6a9cf90299cf75aa46c5 ] Clang can generate R_RISCV_CALL_PLT relocations to _mcount: $ llvm-objdump -dr build/riscv/init/main.o | rg mcount 000000000000000e: R_RISCV_CALL_PLT _mcount 000000000000004e: R_RISCV_CALL_PLT _mcount After this, the __start_mcount_loc section is properly generated and function tracing still works. Link: https://github.com/ClangBuiltLinux/linux/issues/1331 Signed-off-by: Nathan Chancellor Reviewed-by: Fangrui Song Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

scripts/recordmcount.{c,pl}: support -ffunction-sections .text.* section names

2021-03-17T15:43:43Z

commit 9c8e2f6d3d361439cc6744a094f1c15681b55269 upstream. When building with -ffunction-sections, the compiler will place each function into its own ELF section, prefixed with ".text". For example, a simple test module with functions test_module_do_work() and test_module_wq_func(): % objdump --section-headers test_module.o | awk '/\.text/{print $2}' .text .text.test_module_do_work .text.test_module_wq_func .init.text .exit.text Adjust the recordmcount scripts to look for ".text" as a section name prefix. This will ensure that those functions will be included in the __mcount_loc relocations: % objdump --reloc --section __mcount_loc test_module.o OFFSET TYPE VALUE 0000000000000000 R_X86_64_64 .text.test_module_do_work 0000000000000008 R_X86_64_64 .text.test_module_wq_func 0000000000000010 R_X86_64_64 .init.text Link: http://lkml.kernel.org/r/1542745158-25392-2-git-send-email-joe.lawrence@redhat.com Signed-off-by: Joe Lawrence Signed-off-by: Steven Rostedt (VMware) Cc: Manoj Gupta Signed-off-by: Greg Kroah-Hartman

scripts/recordmcount.pl: support big endian for ARCH sh

2021-03-04T08:39:30Z

[ Upstream commit 93ca696376dd3d44b9e5eae835ffbc84772023ec ] The kernel test robot reported the following issue: CC [M] drivers/soc/litex/litex_soc_ctrl.o sh4-linux-objcopy: Unable to change endianness of input file(s) sh4-linux-ld: cannot find drivers/soc/litex/.tmp_gl_litex_soc_ctrl.o: No such file or directory sh4-linux-objcopy: 'drivers/soc/litex/.tmp_mx_litex_soc_ctrl.o': No such file The problem is that the format of input file is elf32-shbig-linux, but sh4-linux-objcopy wants to output a file which format is elf32-sh-linux: $ sh4-linux-objdump -d drivers/soc/litex/litex_soc_ctrl.o | grep format drivers/soc/litex/litex_soc_ctrl.o: file format elf32-shbig-linux Link: https://lkml.kernel.org/r/20210210150435.2171567-1-rong.a.chen@intel.com Link: https://lore.kernel.org/linux-mm/202101261118.GbbYSlHu-lkp@intel.com Signed-off-by: Rong Chen Reported-by: kernel test robot Cc: Yoshinori Sato Cc: Rich Felker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

nds32/ftrace: Add RECORD_MCOUNT support

2018-09-04T06:45:18Z

Recognize NDS32 object files in recordmcount.pl. Signed-off-by: Zong Li Acked-by: Greentime Hu Signed-off-by: Greentime Hu

powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS

2018-06-01T13:08:09Z

The powerpc toolchain can compile combinations of 32/64 bit and big/little endian, so it's convenient to consider, e.g., `CC -m64 -mbig-endian` To be the C compiler for the purpose of invoking it to build target artifacts. So overriding the CC variable to include these flags works for this purpose. Unfortunately that is not compatible with the way the proposed new Kconfig macro language will work. After previous patches in this series, these flags can be carefully passed in using flags instead. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman

Merge tag 'riscv-for-linus-4.17-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux

2018-04-04T23:43:47Z

Pull RISC-V updates from Palmer Dabbelt: "This contains the new features we'd like to incorporate into the RISC-V port for 4.17. We might have a bit more stuff land later in the merge window, but I wanted to get this out earlier just so everyone can see where we currently stand. A short summary of the changes is: - We've added support for dynamic ftrace on RISC-V targets. - There have been a handful of cleanups to our atomic and locking routines. They now more closely match the released RISC-V memory model draft. - Our module loading support has been cleaned up and is now enabled by default, despite some limitations still existing. - A patch to define COMMANDLINE_FORCE instead of COMMANDLINE_OVERRIDE so the generic device tree code picks up handling all our command line stuff. There's more information in the merge commits for each patch set" * tag 'riscv-for-linus-4.17-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: (21 commits) RISC-V: Rename CONFIG_CMDLINE_OVERRIDE to CONFIG_CMDLINE_FORCE RISC-V: Add definition of relocation types RISC-V: Enable module support in defconfig RISC-V: Support SUB32 relocation type in kernel module RISC-V: Support ADD32 relocation type in kernel module RISC-V: Support ALIGN relocation type in kernel module RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module RISC-V: Support CALL relocation type in kernel module RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module RISC-V: Add section of GOT.PLT for kernel module RISC-V: Add sections of PLT and GOT for kernel module riscv/atomic: Strengthen implementations with fences riscv/spinlock: Strengthen implementations with fences riscv/barrier: Define __smp_{store_release,load_acquire} riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support riscv/ftrace: Add DYNAMIC_FTRACE_WITH_REGS support riscv/ftrace: Add ARCH_SUPPORTS_FTRACE_OPS support riscv/ftrace: Add dynamic function graph tracer support riscv/ftrace: Add dynamic function tracer support ...