On 02/08/2024 16:12, Arnd Bergmann wrote: > On Thu, Aug 1, 2024, at 16:15, Richard Earnshaw wrote: >> On 31/07/2024 18:29, Arnd Bergmann wrote: >>> 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. > >>> === 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. > >>> === 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. > >>> 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. > >>> === 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.
