--- Begin Message ---
|
Subject: |
[PATCH] guix: cpu: recognize other architectures. |
|
Date: |
Sun, 15 May 2022 19:11:32 +0200 |
Hi Guix!
The attached patch lets (guix cpu) recognize other architectures. The
code of (current-cpu) is based on the content of /proc/cpuinfo which
can be pretty different on non-intel architectures. For instance,
here's a sample from an armhf machine:
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 45.47
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls
vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 4
In particular, there's no flags entry, so (current-cpu) doesn't stop
until eof, and returns #f.
It's an issue because a test uses this code, for testing manifests with
--tune. If no cpu is returned, the test crashes:
In guix/transformations.scm:
864:25 1 (_ _ _ _ ((package ad-hoc-package "gcc-toolchain")
(<E2><80><A6>) <E2><80><A6>)) In guix/cpu.scm:
94:2 0 (cpu->gcc-architecture #f)
Since the test fails, the "guix" package doesn't build, and I can't
reconfigure on armhf or aarch64. (well armhf has other issues right
now...)
The attached patch changes the logic of the code to read all lines,
find information about the CPU even if it's an ARM CPU, and returns
always something (to prevent the crash) when it reads eof. This means
that it will return architecture information about the last CPU,
instead of the first. I don't think that's an issue because this code
is used for --tune which really only works on intel where you don't
have multiple CPUs with too different features.
WDYT?
0001-guix-cpu-Recognize-other-architectures.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#55431] [PATCH] guix: cpu: recognize other architectures. |
|
Date: |
Tue, 17 May 2022 15:59:15 +0300 |
On Sun, May 15, 2022 at 07:11:32PM +0200, Julien Lepiller wrote:
> Hi Guix!
>
> The attached patch lets (guix cpu) recognize other architectures. The
> code of (current-cpu) is based on the content of /proc/cpuinfo which
> can be pretty different on non-intel architectures. For instance,
> here's a sample from an armhf machine:
>
> processor : 0
> model name : ARMv7 Processor rev 4 (v7l)
> BogoMIPS : 45.47
> Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls
> vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part : 0xc07
> CPU revision : 4
>
> In particular, there's no flags entry, so (current-cpu) doesn't stop
> until eof, and returns #f.
>
> It's an issue because a test uses this code, for testing manifests with
> --tune. If no cpu is returned, the test crashes:
>
> In guix/transformations.scm:
> 864:25 1 (_ _ _ _ ((package ad-hoc-package "gcc-toolchain")
> (<E2><80><A6>) <E2><80><A6>)) In guix/cpu.scm:
> 94:2 0 (cpu->gcc-architecture #f)
>
> Since the test fails, the "guix" package doesn't build, and I can't
> reconfigure on armhf or aarch64. (well armhf has other issues right
> now...)
>
> The attached patch changes the logic of the code to read all lines,
> find information about the CPU even if it's an ARM CPU, and returns
> always something (to prevent the crash) when it reads eof. This means
> that it will return architecture information about the last CPU,
> instead of the first. I don't think that's an issue because this code
> is used for --tune which really only works on intel where you don't
> have multiple CPUs with too different features.
>
> WDYT?
I just pushed mine without seeing yours, sorry.
I did check the gcc source code and I found the options for determining
the cpu flags for arm* processors in gcc/config/arm/arm-cpus.in. Do you
think it'd be worth it to add detection for armv7 CPUs?
Also, I'm pretty sure we can overlap armhf and aarch64 together, and
i686 and x86_64 together, and then running 32-bit code on 64-bit
processors will get a nice boost since it'll be tuned for the actual
hardware.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
--- End Message ---