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
