Message-Id: <80c0dd7d-6b4b-40ae-a4f4-09bb890ba26b@app.fastmail.com>
Date: Tue, 20 Aug 2024 16:33:27 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Richard Earnshaw" <Richard.Earnshaw@....com>,
 linux-arm-kernel@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org, "Russell King" <linux@...linux.org.uk>,
 "Linus Walleij" <linus.walleij@...aro.org>,
 "Richard Sandiford" <richard.sandiford@....com>,
 "Ramana Radhakrishnan" <ramanara@...dia.com>,
 "Nicolas Pitre" <nico@...xnic.net>,
 "Krzysztof Kozlowski" <krzk@...nel.org>,
 "Mark Brown" <broonie@...nel.org>,
 "Kristoffer Ericson" <kristoffer.ericson@...il.com>,
 "Robert Jarzmik" <robert.jarzmik@...e.fr>,
 "Aaro Koskinen" <aaro.koskinen@....fi>,
 "Janusz Krzysztofik" <jmkrzyszt@...il.com>,
 "Tony Lindgren" <tony@...mide.com>,
 Linux-OMAP <linux-omap@...r.kernel.org>,
 "Nikita Shubin" <nikita.shubin@...uefel.me>,
 linux-samsung-soc@...r.kernel.org, "Andrew Lunn" <andrew@...n.ch>,
 "Sebastian Hesselbarth" <sebastian.hesselbarth@...il.com>,
 "Gregory Clement" <gregory.clement@...tlin.com>,
 "Jeremy J. Peper" <jeremy@...emypeper.com>, debian-arm@...ts.debian.org,
 "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
 "Alexandre Torgue" <alexandre.torgue@...s.st.com>
Subject: Re: [RFC} arm architecture board/feature deprecation timeline

On Tue, Aug 20, 2024, at 16:58, Richard Earnshaw wrote:
> On 02/08/2024 16:12, Arnd Bergmann wrote:
>>>> === iWMMXt ===
>>>>
>>>> I'm not aware of any remaining users for iWMMXt, and we dropped
>>>> support for ARMv7 PJ4 CPUs (MMP2, Berlin) already, so the
>>>> only supported hardware that even has this is Intel/Marvell
>>>> PXA and MMP1.
>>>>
>>>> Dropping support from gcc is probably a good idea now,
>>>> it is already unsupported in clang.
>>>
>>> We marked iWMMXt as deprecated in gcc-14 and will likely remove support 
>>> in GCC-15.  We expect to continue supporting these as Armv5T cores, but 
>>> not the iwmmxt (or other XScale) extensions.  
>> 
>> Ok, good to know. The kernel doesn't actually have a build
>> time dependency on gcc's xscale or iwmmxt support aside from the
>> one assembly file we build with gcc -march=xscale.
>
> I think you mean -mcpu=xscale (-march=xscale isn't recognized), or 
> perhaps you mean -march=iwmmxt? 

We currently use "-Wa,-mcpu=iwmmxt", sorry for the mixup.

>>>> === big-endian ARMv7 (BE8) kernel ===
>>>>
>>>> This is very different from BE32 mode in making more sense
>>>> from a kernel point of view. In theory any ARMv7 hardware
>>>> should work, though a lot of drivers are buggy. I am not
>>>> aware of any actual use cases, though in theory it can be
>>>> helpful for testing big-endian userspace when one has
>>>> access to Arm hardware but no other big-endian machine.
>>>>
>>>> We should probably keep this a few more years in both
>>>> toolchain and kernel, unless it starts causing actual
>>>> problems. I don't think anyone is testing it any more
>>>> though.
>>>>
>>>> Side-note: netbsd has a armv7+be8 variant, so clang will
>>>> likely keep supporting be8 even if gcc ends up dropping it
>>>> in the future.
>> 
>> Do you have any comments on BE8 support? I would imagine
>> that having two (mostly) unused big-endian targets in
>> the compiler still complicates things a bit.
>
> The compiler/assembler largely treat BE8 and BE32 the same; the linker 
> then byte-swaps the BE8 instructions during linking to generate BE8 
> images (this is mostly why we need mapping symbols).  That won't really 
> change if we drop BE32 support.  So I don't think we gain much from 
> this.

Right, makes sense. I can never remember the way this is
actually implemented

>> Ok. I can certainly confirm that we regularly run into
>> build problems with -mabi=apcs in the kernel, usually
>> because of the incompatible structure alignment rules.
>> If binutils are dropping support, that also means we will
>> eventually stop supporting it in the kernel.
>
> This is primarily about the arm-elf (as opposed to arm-eabi) object 
> file format, -mabi=apcs doesn't change that.  There are some options in 
> gcc relating to the old APCS that I'd really like to get rid of (in 
> particular -mapcs-frame (aka -mapcs)), but that's a separate issue.

I think I mixed this up as well, what we use for OABI kernels
is "-mabi=apcs-gnu", which creates an "ELF 32-bit LSB relocatable,
ARM, version 1 (ARM)" OABI  file instead of "ELF 32-bit LSB
relocatable, ARM, EABI5 version 1 (SYSV)".

We still use "-mapcs-frame" whenever we enable CONFIG_FRAME_POINTER
(aka -fno-omit-frame-pointer). Frame pointers used to be required
for a number of things in the kernel, now there are only two
places that don't work with the modern unwinder:

- CONFIG_ARCH_CORRECT_STACKTRACE_ON_KRETPROBE -- this should
  be on someone's TODO list, no idea why the implementation was
  never completed for this.

- OABI (-mabi=apcs-gnu) kernels, for the in-kernel stack unwinder

Neither of those is particularly important I think, so deprecating
-mapcs-frame along with -mabi=apcs-gnu for new gcc versions should
be from the kernel perspective.

I'll also send a patch to make both OABI and OABI_COMPAT support
depend on StrongARM, based on the earlier discussion. That way
dropping StrongARM (but not armv4 or fa526) in the future will also
eliminate OABI and nwfpe.

       Arnd

Powered by blists - more mailing lists