Greetings, and thank you so much for your very detailed, clear, and
comprehensive reply!
PER_LINUX_32GB and/or a userspace interface to set the address space
layout would be nice, but my chief concern is that whatever the kernel
provides to userspace be the same on all machines purporting to be of
the same 'architecture'. On further investigation, it appears that
32bit arm(el)(hf) kernels have a 3GB address space, starting the stack
at 0xbfffffff, regardless of the PER_LINUX_32GB personality setting, and
that 32bit compatibility mode on a 64bit kernel provides a 4GB address
space, starting the stack at 0xffffffff, again regardless of
personality, as you state. To me it seems that the 64bit kernel, if it
offers a compatibility mode, should match whatever the contemporaneous
32bit kernel behavior is, making this a bug in the compatibility mode.
Even if this is not deemed a bug, 32bit chroot under 64bit is
effectively a different architecture at present. I suggest that
arm(el)(hf) refer to a genuine 32bit kernel, whatever address space it
chooses to provide, and that therefore as long as this difference is
outstanding, some method in buildd be provided to allow packages to
specify that they should only be built in a 'true' environment. Might
this be possible?
I can put a runtime check in gcl to detect such a mismatch and exit with
an explanatory message for the (hopefully) unlikely case that some
non-developer user wants to run these 32bit binaries under a 64bit
kernel in chroot.
If/when the 32bit address space goes to 3.75GB, that will necessitate a
recompile, but as long as consistency is maintained 32bit binaries can
be distributed and expected to run on machines of the same
'architecture'.
Your thoughts?
Thanks again!
Post by Arnd BergmannPost by Camm MaguireGreetings! There seems to be a subarchitecture within the current 32bit
Debian arm universes and buildds. armv8 processors will leave the C
stack start at 0xffffffff even when personality ADDR_LIMIT_3GB is set,
whereas on armv7 the address starts at 0xbfffffff, as on other 32bit
linux machines.
Is this a bug? Are there other (perhaps gcc?) switches which can match
the armv7 behavior on armv8 machines (e.g. running a armel or armhf
chroot?)
Right now gcl binaries compiled on armv7 will not run on armv8 in a
32bit chroot because of this. Only workaround I see at the moment is to
cripple all gcl 32bit arm binaries and remove immediate fixnum addresses
which should go above 0xc0000000.
Hi Camm,
- Just to clarify, this is unrelated to armv7 vs armv8 processors, only the
kernel running on them. Running a 32-bit kernel on an armv8 CPU
has the same limit as on an armv7 CPU. The generally recommendation
however is to run 64-bit kernels on these CPUs anyway, so this is
indeed a problem in compat mode.
- PER_LINUX32_3GB is technically an x86-only feature, none of the
other architectures with compat mode support (powerpc, s390, sparc,
mips, parisc and arm64) implement this. Unfortunately, there is no
check for invalid arguments to the personality() syscall, so passing this
flag on architectures other than x86 will just silently ignore it. Most of
these will use a 4GB address space here.
- There is ongoing work by Linus Walleij and others to extend 32-bit
arm kernels to also have a wider address space, allowing up to
3.75GB of user space addresses (and also up to 3.75GB of
lowmem). When this is implemented, the application will stop
working on native 32-bit kernels as well.
- It would probably be possible to implement PER_LINUX32_3GB on
all architectures, including native 32-bit ones, if there is demand.
More generally, we have previously discussed adding a kernel
interface to pick an arbitrary maximum user space address limit
per process, which would solve other problems as well. I don't
think anyone is working on that at the moment.
Arnd
--
Camm Maguire ***@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah