Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4973172pxb; Thu, 14 Oct 2021 16:09:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw44O1GKO2OKKJ4FmiDJmSQTuWYyATpODW3QBEAsRVJAyF7vHOTmLv3yaBHDuYZ0IcW/9Mn X-Received: by 2002:a17:90b:4d09:: with SMTP id mw9mr9326639pjb.100.1634252954759; Thu, 14 Oct 2021 16:09:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634252954; cv=none; d=google.com; s=arc-20160816; b=GF1N4gX7GcxOBE6f4iwu6i3ESBE7YrqFRLEmqE/Eg6CehSyTXqj2QnKaCukUqMpZ9k S+shE+pgmZXpF7TmhWd6WFHUw61ibk+j2Xnq4kL3BUFJ94lxbE49dlt9/s5Tc5w+aQex 9Gd0T6qQn5kpUUJc3F/ggLQWiX81imbmXMlma4oteARIMz6ryWmuw1i8Su+iMFJgKyrc B1x/o2Qcy4ATorsoAkjqu+j36FehOTkA9d/+8oaH/uou2Hx576b09TFR2Z+wM8vGYFNd 8ctzN1GgYI5I46rKQC53LXXuLQcoAiXaf1hHjiaO+sGwsvGibaqFfiO++tB7m9I0l26m 4lNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date; bh=hQYKF9uJ/Q+41Cf1jBoeFuk4MnPVeQ5ust1rt5xEN70=; b=iq2OrGmC+ROFox3wb2Vf9AvvoAYfAHH31J/XnrtLfEKs4oRHUAM7JXzCS4cmvgEqu+ qaNL7ls7DMSfxW0wZeuadua/55i9nh8ICDjCP6SIQRTUUToOZLVn4ck40pQmGOhg/UKq +m2aXDVUvEX+sbj+OxYev1FUsc+YZxb9E6sTkgH2DVEnwmhnW/9Z2NFHd2uu5z0CTYxJ 2XgldebwUUCvRgM/GDJrNLDLi+BRNNesX9Je260Pz1wUDd+n5NmTCtAVV7JO6aK+wXBO rmUJ7kU8899uTdrO16vH8T0GXrz/iGd5Ees2j0TmsGw8uHcupqcokZsNNrWzoBg1P6yx 6YKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n3si5929653pgv.117.2021.10.14.16.09.01; Thu, 14 Oct 2021 16:09:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233945AbhJNShQ (ORCPT + 99 others); Thu, 14 Oct 2021 14:37:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:54158 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233937AbhJNShP (ORCPT ); Thu, 14 Oct 2021 14:37:15 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 68D4061156; Thu, 14 Oct 2021 18:35:09 +0000 (UTC) Date: Thu, 14 Oct 2021 14:35:07 -0400 From: Steven Rostedt To: LKML Cc: Nick Hu , Greentime Hu , Vincent Chen , Ingo Molnar , Andrew Morton , Arnd Bergmann , Zong Li , "Gustavo A. R. Silva" , kernel test robot Subject: [PATCH] nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^' Message-ID: <20211014143507.4ad2c0f7@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Resending with "PATCH" in subject ] 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. Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) --- diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl index 8f6b13ae46bf..7d631aaa0ae1 100755 --- a/scripts/recordmcount.pl +++ b/scripts/recordmcount.pl @@ -189,7 +189,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;