user/sven/linux.git/scripts/recordmcount.pl, branch v5.4.250

recordmcount.pl: fix typo in s390 mcount regex

2022-01-05T11:37:44Z

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:29:35Z

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:40:12Z

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-22T09:38:29Z

[ 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-22T09:38:28Z

[ 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.pl: support big endian for ARCH sh

2021-02-26T09:10:28Z

[ 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

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 166

2019-05-30T18:26:39Z

Based on 1 normalized pattern(s): licensed under the terms of the gnu gpl license version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 62 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Kate Stewart Reviewed-by: Richard Fontana Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.929121379@linutronix.de Signed-off-by: Greg Kroah-Hartman

Merge tag 'kbuild-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2019-05-08T19:25:12Z

Pull Kbuild updates from Masahiro Yamada: - allow users to invoke 'make' out of the source tree - refactor scripts/mkmakefile - deprecate KBUILD_SRC, which was used to track the source tree location for O= build. - fix recordmcount.pl in case objdump output is localized - turn unresolved symbols in external modules to errors from warnings by default; pass KBUILD_MODPOST_WARN=1 to get them back to warnings - generate modules.builtin.modinfo to collect .modinfo data from built-in modules - misc Makefile cleanups * tag 'kbuild-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (21 commits) .gitignore: add more all*.config patterns moduleparam: Save information about built-in modules in separate file Remove MODULE_ALIAS() calls that take undefined macro .gitignore: add leading and trailing slashes to generated directories scripts/tags.sh: fix direct execution of scripts/tags.sh scripts: override locale from environment when running recordmcount.pl samples: kobject: allow CONFIG_SAMPLE_KOBJECT to become y samples: seccomp: turn CONFIG_SAMPLE_SECCOMP into a bool option kbuild: move Documentation to vmlinux-alldirs kbuild: move samples/ to KBUILD_VMLINUX_OBJS modpost: make KBUILD_MODPOST_WARN also configurable for external modules kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build kbuild: remove unneeded dependency for include/config/kernel.release memory: squash drivers/memory/Makefile.asm-offsets kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build kbuild: mkmakefile: generate a simple wrapper of top Makefile kbuild: mkmakefile: do not check the generated Makefile marker kbuild: allow Kbuild to start from any directory kbuild: pass $(MAKECMDGOALS) to sub-make as is kbuild: fix warning "overriding recipe for target 'Makefile'" ...

scripts: override locale from environment when running recordmcount.pl

2019-05-03T14:05:01Z

recordmcount.pl uses a set of regular expressions to parse the output of objdump(1). However, if objdump(1) output is localized, it may not match the regular expressions, thereby preventing recordmcount.pl from parsing object files correctly. In order to allow recordmcount.pl to function correctly regardless of the current locale settings, set LANG=C when running objdump(1). LC_ALL is already unset in the top-level Makefile, so it is not necessary to also override that environment variable. Signed-off-by: Daniel Dadap Reviewed-by: Robert Morell Signed-off-by: Masahiro Yamada

csky/ftrace: Add dynamic function tracer (include graph tracer)

2019-04-22T05:44:57Z

Support dynamic ftrace including dynamic graph tracer. Gcc-csky with -pg will produce call site in every function prologue and we can use these call site to hook trace function. gcc with -pg origin call site: push lr jbsr _mcount nop32 nop32 If the (callee - caller)'s offset is in range of bsr instruction, we'll modify code with: push lr bsr _mcount nop32 nop32 Else if the (callee - caller)'s offset is out of bsr instrunction, we'll modify code with: push lr movih r26, ... ori r26, ... jsr r26 (r26 is reserved for jsr link reg in csky abiv2 spec.) Signed-off-by: Guo Ren