From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8CEE419258E for ; Mon, 15 Dec 2025 11:28:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765798109; cv=none; b=QOZzc+qLymnU7vVmsuihQWNbOFsAR3cBWJFs26OHNb1YmL+K6jvkxRMWPNatypALdwYHKoSjr5V2SWvRbaweJzbVvZUb0hMvqUyWQA4Vjn6TGbU3zb8+Agwd3EnkcKkGebCmWmViFln/ErGN6uxTbFaXQn5XqfZIBPO4rnxiim0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765798109; c=relaxed/simple; bh=nJXk9GcwN/rdnhtrh9XbN8R0sKvyNefzyAyFqxCBV38=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tqcqFlI2pENB/X3r/EQoj2VQhVqxI1qY583gU01Epe7G4TJzi6nZQVxQg7BYIXyNanhxJh4SbdUXASAPe9usfndC7e9RMcCsz9iWyLfwJXhNaR+acEJz+lFrhvMD5ppMY/OUmUbgw9T8TkhzZR2LpF6vlnNVHBEFaXMNqLAv4RQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DAB81497; Mon, 15 Dec 2025 03:28:13 -0800 (PST) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9FA853F73B; Mon, 15 Dec 2025 03:28:20 -0800 (PST) Date: Mon, 15 Dec 2025 11:28:18 +0000 From: Leo Yan To: James Clark Cc: Arnd Bergmann , Joel May , Ian Rogers , linux-arm-kernel@lists.infradead.org, Linux perf Profiling , Catalin Marinas , Will Deacon Subject: Re: [PATCH] arm64: perf: fix syscalltbl path base Message-ID: <20251215112818.GB681384@e132581.arm.com> References: <23c07ac4-ff13-47a5-824a-e7af1d1847a3@app.fastmail.com> Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Dec 15, 2025 at 12:52:24PM +0200, James Clark wrote: [...] > On 15/12/2025 11:33, Arnd Bergmann wrote: > > On Mon, Dec 15, 2025, at 09:47, James Clark wrote: > > > On 15/12/2025 00:12, Joel May wrote: > > > > > > Hi Joel, > > > > > > There is a similar fix on the list here: > > > > > > https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/ > > > > > > I'm not sure if commit 1 alone will also fix your issue, or we'd need to > > > collapse both of the commits in that set. We need to apply both patches in the share link - we need to apply the second patch to revert generating unistd_64.h in libperf. > > > The first commit has an older fixes: tag and also fixes some other > > > issues so it might be better to take that one rather than this one. > > > > I don't understand that other "fix", doesn't that just work around > > the arm64 build issue by adding another special case for arm64? > > > > If we want the tools directory to have a copy of the generated unistd.h > > files instead of generating them, it should at the minimum be done > > the same across all architectures. > > I don't think it's a special case, the other architectures already have a > copy of their syscall headers in tools/ don't they? Correct. Most of architectures simply include tools/include/uapi/asm-generic/unistd.h x86 includes their own unistd_32/64.h; only arm64 attempted to generate unistd_64.h dynamically, but this is problem for build dependency - when build perf, feature tests in tools/build/feature/ run before libperf and fail if unistd_64.h has not yet been generated by libperf Makefile. > My original commit that is reverted by Leo's patches is more of a "fix" than > his fix. It turned out that running the generator script for the Perf build > wasn't the best idea after all. Now it's obvious that we'd have to keep > injecting that build rule into every tool that needs it. And it doesn't even > respect this rule described here that tools headers should be decoupled from > the kernel sources: > > linux/tools/include/uapi/README > > I don't see the benefit of manually copying over the generator script and > its input file and then updating every build rule to invoke it when we can > manually copy over the output of that script and not have to do anything > else. > > Ian makes the point that we can run the generator for doing > check_headers.sh. But at least that only needs to be done for one tool and > can be in addition to the manual copy. > > James