[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0bab5f8-ff61-4eee-a736-8c2dbd33bc72@leemhuis.info>
Date: Tue, 29 Apr 2025 10:02:26 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: James Clark <james.clark@...aro.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>, arnd@...aro.org
Subject: Re: [PATCH] perf tools: Fix arm64 build by generating unistd_64.h
On 29.04.25 09:52, James Clark wrote:
> On 29/04/2025 8:42 am, James Clark wrote:
>> On 28/04/2025 2:23 pm, Thorsten Leemhuis wrote:
>>> On 17.04.25 15:55, James Clark wrote:
>>>> Since pulling in the kernel changes in commit 22f72088ffe6 ("tools
>>>> headers: Update the syscall table with the kernel sources"), arm64 is
>>>> no longer using a generic syscall header and generates one from the
>>>> syscall table. Therefore we must also generate the syscall header for
>>>> arm64 before building Perf.
>>>>
>>>> Add it as a dependency to libperf which uses one syscall number. Perf
>>>> uses more, but as libperf is a dependency of Perf it will be generated
>>>> for both.
>>>>
>>>> Future platforms that need this will have to add their own syscall-y
>>>> targets in libperf manually. Unfortunately the arch specific files that
>>>> do this (e.g. arch/arm64/include/asm/Kbuild) can't easily be imported
>>>> into the Perf build. But Perf only needs a subset of the generated
>>>> files
>>>> anyway, so redefining them is probably the correct thing to do.
>>>
>>> FYI, my daily -next build for Fedora based on its RPM spec file broke
>>> on arm64 (x86_64 worked fine) while building libperf. I haven't checked
>>> yet, but due to the error messages and a quick look in the history I
>>> wonder if this is due to the quoted change, which showed up in -next
>>> today:
>>>
>>> """
>>> kernel.spec:3115: build libperf
>>> + /usr/bin/make -s 'EXTRA_CFLAGS=-O2 -fexceptions -g -grecord-gcc-
>>> switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security
>>> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -
>>> specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-
>>> strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-
>>> protection=standard -fasynchronous-unwind-tables -fstack-clash-
>>> protection ' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-
>>> relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-
>>> hardened- ld -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -
>>> specs=/usr/ lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -
>>> specs=/usr/ lib/rpm/redhat/redhat-package-notes ' -C tools/lib/perf
>>> V=1 DESTDIR=/ builddir/build/BUILD/kernel-6.15.0-build/BUILDROOT
>>> mkdir: cannot create directory ‘/../arch’: Permission denied
>>> /builddir/build/BUILD/kernel-6.15.0-build/kernel-next-20250428/
>>> linux-6.15.0-0.0.next.20250428.435.vanilla.fc43.aarch64/scripts/
>>> syscallhdr.sh: line 98: /../arch/arm64/include/generated/uapi/asm/
>>> unistd_64.h: No such file or directory
>>> make[2]: *** [/builddir/build/BUILD/kernel-6.15.0-build/kernel-
>>> next-20250428/
>>> linux-6.15.0-0.0.next.20250428.435.vanilla.fc43.aarch64/ scripts/
>>> Makefile.asm-headers:81: /../arch/arm64/include/generated/ uapi/asm/
>>> unistd_64.h] Error 1
>>> make[1]: *** [Makefile:108: uapi-asm-generic] Error 2
>>> make: *** [Makefile:128: all] Error 2
>>> error: Bad exit status from /var/tmp/rpm-tmp.vAfil2 (%build)
>>> """
>>>
>>> Full log: https://download.copr.fedorainfracloud.org/results/@kernel-
>>> vanilla/next/fedora-rawhide-aarch64/08975350-next-next-all/builder-
>>> live.log.gz
>>
>> Yes, this is the error that the fix is for.
>
> Sorry I had it the wrong way around,
Okay, for a moment I was confused and wondered if I was holding things
wrong. :-D
> I see you were asking about a new
> build failure caused by the fix. Looking into it now.
Many thx!
> I noticed some strange characters in here
Sorry, that was my (or my browsers) fault (some encoding mixup somewhere
I've seen earlier) and highly unlikely to be related.
> mkdir: cannot create directory ‘/../arch’: Permission denied
Ciao, Thorsten
Powered by blists - more mailing lists