GNU bug report logs - #55431
[PATCH] guix: cpu: recognize other architectures.

Previous Next

Full log

View this message in rfc822 format

From: Julien Lepiller <julien <at> lepiller.eu>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 55431-done <at> debbugs.gnu.org
Subject: [bug#55431] [PATCH] guix: cpu: recognize other architectures.
Date: Tue, 17 May 2022 17:55:38 +0200

[Message part 1 (text/plain, inline)]

Thanks for fixing that anyway :)

I was only interested in it because it made me unable to reconfigure my systems. I don't care too much about the --tune code, and I don't understand what you suggest. Do you mean to create "x86 on x86_64" as a separate architecture? Or as a --tune target?

On May 17, 2022 2:59:15 PM GMT+02:00, Efraim Flashner <efraim <at> flashner.co.il> wrote:
>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 <at> 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.