On 02/08/2024 16:12, Arnd Bergmann wrote:

On Thu, Aug 1, 2024, at 16:15, Richard Earnshaw wrote:

quoted

On 31/07/2024 18:29, Arnd Bergmann wrote:

quoted

  This is used for both StrongARM and FA526 CPUs, which are still
  used on a small number of boards. Even the newest chips (moxa
  art, ) are close to 20 years olds but were still in use a few years
  ago. The last Debian release for these was Lenny (5.0).

  Dropping compiler support now would be appropriate IMHO, and
  we can drop kernel support in a few years.

This is good to know.  The lack of Thumb (particularly the lack of BX) on these
CPUs is a major wart we still have to handle in the compiler.

See also my (too long) reply to Linus Walleij. He thinks we may
want to support ARMv4 a little longer, but hopefully we can reach
a consensus about how long exactly.

quoted

quoted

=== 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?  Either way, if this is an assembly file, then you can just add the appropriate '.arch' (and/or .cpu) directives to the source file and then the command line options can be dropped.

quoted

quoted

=== 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.

quoted

quoted

I would propose to leave the feature in the kernel but
make it harder to enable by accident, changing the default
for all targets to EABI and adding a dependency on
'CPU_32v4 || EXPERT'.

For the compiler, I think removing support for -mabi=apcs
makes sense, unless there are non-Linux targets that still
use this.

Gas 2.43 (finally) drops support for the FPA and Maverick. gas 2.44 
may well drop support for OABI binaries (arm-none-elf, as opposed to 
arm-none-eabi).  Support for these is probably buggy now and it is 
certainly making maintenance more difficult.

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.

quoted

quoted

=== NWFPE ===

Russell had a patch set to remove this 11 years ago,
but ended up keeping it. This is fundamentally tied
to OABI userland, so we'll likely need to keep it for
as long as either OABI or OABI_COMPAT remains.

See above re FPA removal from GAS.  GCC removed FPA support in 2012!

Right, for us this is clearly only done for legacy user
binaries. It is still possible to run an OABI Debian-5.0
or older rootfs with a new kernel, but there are not a lot
of reasons to do so, other than ARMv4 (StrongARM)
hardware. The only times I ever tried using it were
to test kernel changes that impact OABI syscall handling.

That's what I'd expect by this point.  The main difficulty would come in reconstructing test-cases for this (if you have any), since the tools will no-longer be able to do that.

R.