Updated list of machines with 4GB or more

Posted Feb 29, 2020 1:23 UTC (Sat) by clopez (guest, #66009)
In reply to: Updated list of machines with 4GB or more by arnd
Parent article: An end to high memory?

> Calxeda Midway servers used in build farms for native 32-bit builds to avoid differences in compilation results between running on 32-bit and 64-bit kernels, usually with 16GB of RAM.

How can be posible that a compiler produces different results depending on the kernel running the compiler (instead of depending on the kernel targeted by the compiler)?
How crosscompilers even work then?

Updated list of machines with 4GB or more

Posted Feb 29, 2020 10:12 UTC (Sat) by rossburton (subscriber, #7254) [Link]

I’m guessing the point was to do native and not cross compilation.

Updated list of machines with 4GB or more

Posted Feb 29, 2020 10:48 UTC (Sat) by arnd (subscriber, #8866) [Link]

> How can be posible that a compiler produces different results depending on the kernel running the compiler (instead of depending on the kernel targeted by the compiler)?

This is about building entire packages, not just a single source file, so a lot of differences between native 32-bit kernels and compat mode can be relevant, though it would usually be a bug in a package if they are:

* The contents of /proc/cpuinfo, uname or the cpuid registers are different, which can confuse configure scripts in all kinds of ways, such as thinking they are cross-compiling when they should be building natively, or being unable to parse the incompatible /proc/cpuinfo format. Simply changing these to look like an ARMv7 CPU would be bad for applications that have a legitimate interest in finding out the actual CPU type on a 64-bit kernel.

* For doing local builds, upstream maintainers may default to using -march=native, but when building a distro package you normally want to target the minimum supported CPU instead. This bug can also hit when building an ARMv6 package on an ARMv7VE host just as it can when building an i586 package on Skylake x86-64 host.

* The compat mode in the kernel is a pretty good approximation of the native interfaces, but there are always a few differences -- usually those are bugs in compat handling, but there is also sysvipc being broken on native sparc32 kernels or such as arm32 kernels traditionally not having NUMA syscalls, both of which worked fine on 64-bit compat mode.

* On 64-bit kernels, you usually have 4GB of virtual address space for user space, while native kernels have only 3GB or less. This is great for most applications, but it can cause problems in a runtime environment that treats any high pointer value as a special cookie.

Some of these can be worked around using the 'personality' interfaces, others should probably be configurable the same way, and some should just be considered bugs that need to be fixed in upstream user space packages. I personally think the build systems should use 64-bit kernels with 32-bit user space and fix the resulting bugs, but it's not my decision.

> How crosscompilers even work then?

You can probably cross-compile a majority of all packages in a distro these days, but there are enough exceptions that Debian or OBS decide to only build packages natively.