Re: _ioperm support for Arm

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 29 May 2019, Phil Blundell wrote:

> You're correct that it isn't practical for an ARMv4 machine to be 
> EABI conformant because the EABI mandates interworking and ARMv4 
> doesn't have BX/BLX, but last time I looked glibc did still have
> all the right conditional guards in place to allow for compilation
> on an ARMv4 platform.  I haven't checked recently though and it's

The EABI fully supports v4t (though I haven't tested glibc on v4t hardware 
for a few years), but not v4.  There are two ways in which there can be 
some limited support for the EABI on v4:

* --fix-v4bx can be passed to the assembler and linker (and GCC does so 
automatically for v4).  When passed to the assembler, it results in 
R_ARM_V4BX relocations on BX instructions; when passed to the linker, it 
results in those instructions being rewritten into a form that works on v4 
(so the .o files are interworking-safe but can also be used on v4 if the 
linker option is used).  This is mainly useful in bare-metal contexts with 
static linking only; it's not so good in a dynamic linking context where 
linked Arm code in an executable might later get run with Thumb code in a 
shared library on a newer processor.

* With --fix-v4bx-interworking passed to the linker, BX instructions 
(marked with R_ARM_V4BX) are converted to branch to veneers (with the 
caveats in the linker manual about how that may clobber condition flags 
that aren't meant to be clobbered by branches, so isn't strictly 
EABI-conforming).  This allows executables and shared libraries to be 
produced that work on v4 and are interworking-safe on v4t.  This option 
was added because there was some desire at the time for distributions - 
the Debian EABI port, at least - to be able to work on v4 hardware while 
still using the EABI, but I'm not sure if anyone ever actually made 
serious use of it in the end.

The conditionals in glibc's sysdeps/arm/sysdep.h, and consequent BX macro, 
do something simpler: allow code to build for v4 but without any attempt 
to make it interworking-safe on later architecture versions.  It would not 
surprise me at all if that support for almost-EABI-but-not-interworking 
code supporting v4 is in fact bitrotten, and I've never tried to build 
such a configuration at all.  I think removing the attempt to support v4 
(as opposed to v4t) would be reasonable.

-- 
Joseph S. Myers
joseph@codesourcery.com