Support sharing ARM headers for hard and soft float

Support sharing ARM headers for hard and soft float

[Joseph S. Myers]

Different dynamic linker names for ARM hard and soft float ABIs means 
different gnu/lib-names.h contents - but it is desirable for one compiler 
to be able to target multilibs with both ABIs using a single set of 
headers.  I've applied this patch to use the new general biarch/triarch 
support for generated headers to build a gnu/lib-names.h supporting both 
ABIs.  (syscall.h and stubs.h should always get identical contents for 
both ABIs, the issue is just for gnu/lib-names.h.)

diff --git a/ChangeLog.arm b/ChangeLog.arm
index 9a3962e..f57a2e1 100644
--- a/ChangeLog.arm
+++ b/ChangeLog.arm
@@ -1,5 +1,17 @@
 2012-05-30  Joseph Myers  <joseph@codesourcery.com>
 
+	* sysdeps/unix/sysv/linux/arm/Makefile (default-abi-prog): New
+	variable.
+	(default-abi): Likewise.
+	(abi-includes): Likewise.
+	(abi-variants): Likewise.
+	(abi-soft-options): Likewise.
+	(abi-soft-condition): Likewise.
+	(abi-soft-ld-soname): Likewise.
+	(abi-hard-options): Likewise.
+	(abi-hard-condition): Likewise.
+	(abi-hard-ld-soname): Likewise.
+
 	* sysdeps/unix/sysv/linux/arm/kernel-features.h
 	(__ASSUME_TRUNCATE64_SYSCALL): Remove.
 
diff --git a/sysdeps/unix/sysv/linux/arm/Makefile b/sysdeps/unix/sysv/linux/arm/Makefile
index fb1e3a5..d9eb10c 100644
--- a/sysdeps/unix/sysv/linux/arm/Makefile
+++ b/sysdeps/unix/sysv/linux/arm/Makefile
@@ -65,3 +65,29 @@ LDFLAGS-tst-rfc3484 += $(common-objpfx)csu/libc-do-syscall.o
 LDFLAGS-tst-rfc3484-2 += $(common-objpfx)csu/libc-do-syscall.o
 LDFLAGS-tst-rfc3484-3 += $(common-objpfx)csu/libc-do-syscall.o
 endif
+
+define default-abi-prog
+echo '#ifdef __ARM_PCS_VFP';
+echo 'hard';
+echo '#else';
+echo 'soft';
+echo '#endif'
+endef
+default-abi := $(strip $(shell \
+    ($(default-abi-prog)) | $(CC) $(CFLAGS) $(CPPFLAGS) -E -P -))
+ifeq ($(default-abi),hard)
+# OK.
+else
+ifneq ($(default-abi),soft)
+Unknown ABI, must be "hard" or "soft".
+endif
+endif
+
+abi-includes :=
+abi-variants := soft hard
+abi-soft-options := -U__ARM_PCS_VFP
+abi-soft-condition := !defined __ARM_PCS_VFP
+abi-soft-ld-soname := ld-linux.so.3
+abi-hard-options := -D__ARM_PCS_VFP
+abi-hard-condition := defined __ARM_PCS_VFP
+abi-hard-ld-soname := ld-linux-armhf.so.3

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Support sharing ARM headers for hard and soft float

[Roland McGrath]

> +default-abi := $(strip $(shell \
> +    ($(default-abi-prog)) | $(CC) $(CFLAGS) $(CPPFLAGS) -E -P -))

Using $(shell ...) in makefiles is pretty disgusting.  The compiler
will run every time you run make.  What I'd recommend instead is
generating a makefile and including it.  The generated file can depend
on config.make or something like that to be sure it gets re-run when
$(CC) et al might reasonably be expected to have changed.

Re: Support sharing ARM headers for hard and soft float

[Joseph S. Myers]

On Wed, 30 May 2012, Roland McGrath wrote:

> > +default-abi := $(strip $(shell \
> > +    ($(default-abi-prog)) | $(CC) $(CFLAGS) $(CPPFLAGS) -E -P -))
> 
> Using $(shell ...) in makefiles is pretty disgusting.  The compiler
> will run every time you run make.  What I'd recommend instead is
> generating a makefile and including it.  The generated file can depend
> on config.make or something like that to be sure it gets re-run when
> $(CC) et al might reasonably be expected to have changed.

What I really want here is an AC_SUBSTed makefile variable, set by the 
same configure test that puts a definition in config.h with AC_DEFINE.  
But I think that's harder to do cleanly (completely independently for each 
port) than sorting out the config.h issue (bug 14068); autoconf appears to 
want to put all the AC_SUBSTed variables in one shell variable setting in 
configure initialization, which isn't really conducive to configure 
fragments adding their own.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Support sharing ARM headers for hard and soft float

[Roland McGrath]

> What I really want here is an AC_SUBSTed makefile variable, set by the 
> same configure test that puts a definition in config.h with AC_DEFINE.  
> But I think that's harder to do cleanly (completely independently for each 
> port) than sorting out the config.h issue (bug 14068); autoconf appears to 
> want to put all the AC_SUBSTed variables in one shell variable setting in 
> configure initialization, which isn't really conducive to configure 
> fragments adding their own.

Indeed.  Perhaps you could use an AC_CONFIG_COMMANDS to write an extra file
like config.arm.make manually.  I'm not sure there's any special reason to
prefer that over a makefile-generated makefile.  Either one is far better
than using $(shell ...), which nobody should ever do.


Thanks,
Roland