linux-kernel - Re: [PATCH] MIPS: Implement ARCH_HAS_CC_CAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260105100507-14db55e3-aa71-48bf-a6ac-33b186bd082f@linutronix.de>
Date: Mon, 5 Jan 2026 10:43:30 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
	linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Implement ARCH_HAS_CC_CAN_LINK

On Sat, Jan 03, 2026 at 08:36:46PM +0000, Maciej W. Rozycki wrote:
> On Fri, 2 Jan 2026, Thomas Weißschuh wrote:

(...)

> > > Also does the n32 ABI have to be factored in, since IIUC this 
> > > stuff is about user programs?
> > 
> > It can be added, but I don't think it makes much sense.
> > It would only be used if CONFIG_MIPS32_N32=y (which is non-default) and if
> > the toolchain which has no n64 libc, but does have a n32 libc.
> > This seems unlikely to me, but let me know if I am mistaken.
> 
>  My observation over the years has been that n32 has become the industry 
> standard for 64-bit MIPS configurations; it's the default arrangement too 
> for the GNU compiler for `mips64*-*-linux-gnu' targets in the absence of 
> explicit `--with-abi=64' `configure' option, and no multilib support may 
> have been enabled in the compiler (which is not required to build Linux, 
> as 64-bit MIPS GCC and binutils are always able to produce code for all 
> the ABIs regardless).

(...)

>  It's not clear to me offhand how the infrastructure concerned here is 
> used, but it may make sense to default to either NewABI and resort to the 
> other if the default turns out unsupported in a given environment.  This 
> for a change I cannot decide on based on information I've gathered so far.

This infrastructure is currently used for example programs which are part of
the kernel tree. I also want to extend it to test programs [0].
While CONFIG_MIPS32_N32 is optional and off by default on the kernel side, it
seems to be enabled by all the relevant defconfigs. Given that it is the
default on the toolchain side, I agree that it is probably the right choice.

[0] https://lore.kernel.org/lkml/20250717-kunit-kselftests-v5-0-442b711cde2e@linutronix.de/


Thomas