Re: [RFC} arm architecture board/feature deprecation timeline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux