C++ Logo

std-proposals

Advanced search

Re: [std-proposals] ABI

From: Thiago Macieira <thiago_at_[hidden]>
Date: Sun, 14 Jul 2024 07:47:14 -0700
On Sunday 14 July 2024 07:30:45 GMT-7 Thiago Macieira via Std-Proposals wrote:
> > Shouldn't x86_64
> > functions just map to 32bit address when linked to 32bit applications?
>
> If that had been the design, maybe. It wasn't. There's no mechanism on ELF
> platforms to even load a 64-bit piece of code on a 32-bit application or
> vice- versa: the loader refuses to open and interpret an ELF binary that is
> of the wrong class or data order.

The ELF machine type isn't even the same, actually.

When 64-bit x86 and ARM were designed, both actually reserved the 32-bit mode
for their new machine types for a ILP32 content running in the same processor
mode (what in x86-land we called "x32"). The idea was to have the cake and eat
it too: have access to the wider register set (16 registers in x86-64, 32
registers in AArch64), better support for 64-bit quantities, and in the case
of x86, better support for position-relative data access, while still keeping
32-bit-wide pointers for data compactness. This would also allow easier
porting of applications that were not 64-bit ready.

x32 mode was added to the Linux kernel but is on the verge of being removed
due to lack of use and support. ILP32 AArch64 was never even added. ILP32
IA-64 was designed in 2001 when this type of conversion was far more relevant
but was not added to Linux either.

PS: PPC64 is a different machine from PPC 32-bit type in ELF too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering

Received on 2024-07-14 14:47:16