From: Steven Rostedt rostedt@goodmis.org
stable inclusion from stable-5.10.75 commit 7ef43c0f68fb6d5c00c7ac32538b2e988d6a38e2 bugzilla: 182987 https://gitee.com/openeuler/kernel/issues/I4I3MP
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
--------------------------------
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_<object_base_name>.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 green.hu@gmail.com Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Chen Jun chenjun102@huawei.com Acked-by: Weilong Chen chenweilong@huawei.com
Signed-off-by: Chen Jun chenjun102@huawei.com --- scripts/recordmcount.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl index 4f84657f55c2..f459ae883a0a 100755 --- a/scripts/recordmcount.pl +++ b/scripts/recordmcount.pl @@ -222,7 +222,7 @@ if ($arch =~ /(x86(_64)?)|(i386)/) { $local_regex = "^[0-9a-fA-F]+\s+t\s+(\S+)"; $weak_regex = "^[0-9a-fA-F]+\s+([wW])\s+(\S+)"; $section_regex = "Disassembly of section\s+(\S+):"; -$function_regex = "^([0-9a-fA-F]+)\s+<(.*?)>:"; +$function_regex = "^([0-9a-fA-F]+)\s+<([^^]*?)>:"; $mcount_regex = "^\s*([0-9a-fA-F]+):.*\s(mcount|__fentry__)$"; $section_type = '@progbits'; $mcount_adjust = 0;