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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2601031930080.14570@angie.orcam.me.uk>
Date: Sat, 3 Jan 2026 20:36:46 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
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 Fri, 2 Jan 2026, Thomas Weißschuh wrote:

> >  There are no `-m32'/`-m64' options with MIPS GCC; where did you get them 
> > from and how did you verify your change?  Did you mean `-mabi=...' by any 
> > chance?
> 
> Yes indeed. Not sure how that happened, I do have a correct version in
> another branch...  Thanks for spotting this.

 Great!

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

 I've always been an n64 ABI advocate and I used to build pure-n64 64-bit 
environments, but I appreciate that it makes sense for an embedded target 
to use n32 instead, as a lot of code and data space is wasted for the 
handling of 64-bit pointers the upper 33 bits of which may never hold 
anything but zero in many deployments.  Which is also why `-msym32' is 
used to build Linux where the upper 33 bits of immediate kernel addresses 
are known to always hold all-ones.

 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.

  Maciej