64 bit architectures give you 64-bit registers and a 64-bit address space (since pointers are, traditionally, integers that fit in registers[1]). On x86, there are a number of other advantages to using the 64-bit long mode: guaranteed SSE so you don't need slow x87 code, more registers, PC-relative addressing (useful for position-independent code) and so on. The cost of using these is that now every pointer is bigger. This has knock-on effects in terms of data cache usage.

The X32 ABI allows you to have all of the benefits of the 64-bit mode except for the larger address space. If you're using under 4GB of memory, then it can, in theory give an improvement in memory and cache usage.

There are two down sides. The first is that, in my testing of C, C++ and Objective-C code, I've found that it's very rare on a 64-bit platform for pointers to account for even 10% of the total memory usage, and usually it's a lot less. This is made worse by the fact that the X64 and X32 ABIs are incompatible, so you may need two copies of the same library in memory if you have code using both.

I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.

[1] Not with the architecture I'm currently working with, and I'm spending a lot of time fixing compiler assumptions that this is always the case.

If someone could explain to me why x86 architecture is suddenly named x32

It's not. X32 is the name of a programming model, not an architecture. And the X32 programming model cannot be used on the x86 architecture, X32 is a programming model for the AMD64 architecture.

The most important aspect of a programming model for C is that it defines the sizes of basic types like char, short, int, long, and pointers. Many other aspects follow more or less directly from the sizes of those types. X32 is unusual in that it is 64 bit code, but pointers are only 32 bits. When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.

X32 is for running 32-bit apps in a 64-bit native execution environment.

On Windows this practice is called "thunking" or "Windows-on-Windows", where it takes the form of a partially emulated legacy kernel which then backhands its requests to the real kernel.

On Linux, since we usually compile things for the platform as-needed, it's more about efficiency than compatibility. If you don't need 64-bit processing, sometimes it's faster to stick with 32-bit code. If you can live with the 4gb address space, your pointers are half the size, resulting in a smaller memory footprint, which then reduces cache pressure, potentially yielding significant speed improvements for some workloads. Due to the use of 32-bit pointers in this scenario, a 32-bit compatibility layer is required to interface with system libraries. You can't just stick a 32-bit libc and expect it to work, because of its intimate relationship with the kernel.

I think there are more advantages. Think embedded device, which is a market X86 is trying to move into.

Neither Windows nor Mac OS X uses glibc, so it is not a problem. gcc uses the appropriate libc for the platform.

That you can no longer run Linux executables based on the a.out format. The a.out format was phased out in 1996.

No, nobody does.

No, because people stopped using the a.out format to store Linux executables long before Linux started appearing on embedded devices. On a side note, many MCUs use ELF as their preferred executable format, so I don't think there's a "size" problem with it.

No, that's why nobody has used it since 1997. Even if it was competitive with ELF, and it isn't, maintaining two different binary formats to contain the executables of the same OS would be overkill - especially almost 20 years after the first format has been deprecated.

Glibc is only for running Linux or Hurd (I think) executables. These OSes only use ELF. Glibc never ran on Windows or Mac. GCC is a completely separate project, and of course it supports generating executables for Windows, hence it will target PE/COFF of course on those OSes. There is no relationship with Glibc.

The goal is to merge eglibc back into glibc, yes. After the previous glibc steering committee disbanded [h-online.com], it switched to being run by an informal three-person committee, one of whom (Joseph Myers) is also one of the lead maintainers of eglibc, so the two projects' leadership are no longer at odds. And Myers has suggested [sourceware.org] that the goal is to start moving eglibc changes over into the main glibc branch.