New path for ld.so on ARM hard fp

New path for ld.so on ARM hard fp

[Andrew Haley]

We had a meeting to decide what ld.so on ARM hard fp should be called.
This meeting included representatives from all the main distros and
gcc.

https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

The summary was:

All the people in the meeting agreed: the new runtime linker path for
ARM hard-float Linux binaries was to be

/lib/ld-linux-armhf.so.3

Joseph, can you do this please?  Or would you like someone to
submit a patch?

Thanks,
Andrew.

Re: New path for ld.so on ARM hard fp

[Andrew Haley]

On 04/13/2012 06:27 PM, Andrew Haley wrote:
> We had a meeting to decide what ld.so on ARM hard fp should be called.
> This meeting included representatives from all the main distros and
> gcc.
> 
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
> 
> The summary was:
> 
> All the people in the meeting agreed: the new runtime linker path for
> ARM hard-float Linux binaries was to be
> 
> /lib/ld-linux-armhf.so.3
> 
> Joseph, can you do this please?

Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
like to pick this up?

Thanks,
Andrew.

Re: New path for ld.so on ARM hard fp

[Roland McGrath]

> Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
> like to pick this up?

Only Joseph is authoritative.

Re: New path for ld.so on ARM hard fp

[Carlos O'Donell]

On Fri, Apr 13, 2012 at 1:35 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
>> like to pick this up?
>
> Only Joseph is authoritative.

The distro community has reached consensus.

IMO the glibc community should rely on the experience of the distro
community to guide us on such issues.

I plan to create the change, test it, post the patch, ask for review
and commit as long as others don't see anything technically wrong with
this change.

During that time I will attempt to get Joseph's feedback on the
change, but may fail to do so. I don't see that this blocks the patch
checkin to our development *trunk*.

Cheers,
Carlos.

Re: New path for ld.so on ARM hard fp

[Joseph S. Myers]

On Fri, 13 Apr 2012, Andrew Haley wrote:

> We had a meeting to decide what ld.so on ARM hard fp should be called.
> This meeting included representatives from all the main distros and
> gcc.
> 
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
> 
> The summary was:
> 
> All the people in the meeting agreed: the new runtime linker path for
> ARM hard-float Linux binaries was to be
> 
> /lib/ld-linux-armhf.so.3
> 
> Joseph, can you do this please?  Or would you like someone to
> submit a patch?

Please send the patch.  I expect you'll need to change 
sysdeps/arm/preconfigure to add a new sysdeps directory with a new 
shlib-versions file using the new name, if __ARM_PCS_VFP is defined.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: New path for ld.so on ARM hard fp

[Andrew Haley]

On 04/14/2012 05:34 PM, Carlos O'Donell wrote:
> On Fri, Apr 13, 2012 at 1:35 PM, Roland McGrath <roland@hack.frob.com> wrote:
>>> Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
>>> like to pick this up?
>>
>> Only Joseph is authoritative.
>
> The distro community has reached consensus.
>
> IMO the glibc community should rely on the experience of the distro
> community to guide us on such issues.
>
> I plan to create the change, test it, post the patch, ask for review
> and commit as long as others don't see anything technically wrong with
> this change.
>
> During that time I will attempt to get Joseph's feedback on the
> change, but may fail to do so. I don't see that this blocks the patch
> checkin to our development *trunk*.

What's happening with this?

Andrew.

Re: New path for ld.so on ARM hard fp

[Carlos O'Donell]

On Mon, Apr 23, 2012 at 4:41 AM, Andrew Haley <aph@redhat.com> wrote:
> On 04/14/2012 05:34 PM, Carlos O'Donell wrote:
>> On Fri, Apr 13, 2012 at 1:35 PM, Roland McGrath <roland@hack.frob.com> wrote:
>>>> Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
>>>> like to pick this up?
>>>
>>> Only Joseph is authoritative.
>>
>> The distro community has reached consensus.
>>
>> IMO the glibc community should rely on the experience of the distro
>> community to guide us on such issues.
>>
>> I plan to create the change, test it, post the patch, ask for review
>> and commit as long as others don't see anything technically wrong with
>> this change.
>>
>> During that time I will attempt to get Joseph's feedback on the
>> change, but may fail to do so. I don't see that this blocks the patch
>> checkin to our development *trunk*.
>
> What's happening with this?

I just finished a set of WIP patches for this. I'll post them tomorrow morning.

Cheers,
Carlos.

[WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On 4/23/2012 4:41 AM, Andrew Haley wrote:
> On 04/14/2012 05:34 PM, Carlos O'Donell wrote:
>> On Fri, Apr 13, 2012 at 1:35 PM, Roland McGrath <roland@hack.frob.com> wrote:
>>>> Mmm, Joseph is away.  Would one of the regular ARM libc maintainers
>>>> like to pick this up?
>>>
>>> Only Joseph is authoritative.
>>
>> The distro community has reached consensus.
>>
>> IMO the glibc community should rely on the experience of the distro
>> community to guide us on such issues.
>>
>> I plan to create the change, test it, post the patch, ask for review
>> and commit as long as others don't see anything technically wrong with
>> this change.
>>
>> During that time I will attempt to get Joseph's feedback on the
>> change, but may fail to do so. I don't see that this blocks the patch
>> checkin to our development *trunk*.
> 
> What's happening with this?

Summary:
========

* Patch gcc to use the new dynamic linker name.

* Patch glibc to...

  * Detect dynamic linker used by the compiler with the given options.

  * If the compiler and options would select the new dynamic
    linker then use that dynamic linker name for building glibc.

Compatibility for old hard-float binaries is left up to the distros.

I'm using the following GCC patch for testing. It is not the same 
as upstream. Upstream is currently broken because it uses named 
enumerations in a cpp macro equality.

(a) GCC patches:

Index: arm.h
===================================================================
--- arm.h       (revision 368507)
+++ arm.h       (working copy)
@@ -378,9 +378,9 @@

 enum float_abi_type
 {
-  ARM_FLOAT_ABI_SOFT,
-  ARM_FLOAT_ABI_SOFTFP,
-  ARM_FLOAT_ABI_HARD
+  ARM_FLOAT_ABI_SOFT = __ARM_FLOAT_ABI_SOFT,
+  ARM_FLOAT_ABI_SOFTFP = __ARM_FLOAT_ABI_SOFTFP,
+  ARM_FLOAT_ABI_HARD = __ARM_FLOAT_ABI_HARD
 };

 extern enum float_abi_type arm_float_abi;
Index: linux-eabi.h
===================================================================
--- linux-eabi.h        (revision 368507)
+++ linux-eabi.h        (working copy)
@@ -31,10 +31,14 @@
     }                                          \
   while (false)

+#define __ARM_FLOAT_ABI_SOFT 0
+#define __ARM_FLOAT_ABI_SOFTFP 1
+#define __ARM_FLOAT_ABI_HARD 2
+
 /* We default to a soft-float ABI so that binaries can run on all
    target hardware.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
-#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define TARGET_DEFAULT_FLOAT_ABI __ARM_FLOAT_ABI_SOFT

 /* We default to the "aapcs-linux" ABI so that enums are int-sized by
    default.  */
@@ -62,7 +66,17 @@
 /* Use ld-linux.so.3 so that it will be possible to run "classic"
    GNU/Linux binaries on an EABI system.  */
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#if TARGET_DEFAULT_FLOAT_ABI == __ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+    %{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */
===

With the following glibc 2.15 patches:

The patches for trunk are almost identical modulo the
removal of the "eabi" directory since trunk is EABI-only.

(b) Detect dynamic linker used by compiler.

The following new configure test detects the dynamic linker
used by the compiler given the current set of options.
We store the result in libc_cv_compiler_dynlinker_default
for later use in ARM's preconfigure.

As far as I can tell nothing in this test is Linux specific.
We are using ELF terminology to detect the dynamic loader by
name and make no assumptions about the name except that we
assume that readelf returns the name in a given layout.

2012-04-26  Carlos O'Donell  <carlos_odonell@mentor.com>

	* configure.in: Check and set libc_cv_compiler_dynlinker_default.
	* configure: Regenerate.

Index: configure.in
===================================================================
--- configure.in        (revision 368507)
+++ configure.in        (working copy)
@@ -2432,6 +2432,31 @@
 dnl See sysdeps/mach/configure.in for this variable.
 AC_SUBST(mach_interface_list)

+dnl Determine the dynamic linker that the compiler would have used given
+dnl options we have been given. This is useful for machines to know so
+dnl compute it here and have it available for things like ABI checking.
+AC_CACHE_CHECK([what dynamic linker is used by the compiler], libc_cv_complier_dynlinker_default,
+[libc_cv_compiler_dynlinker_default=""
+cat > conftest.c <<EOF
+int main (void) {}
+EOF
+  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS
+                       -o conftest conftest.c
+                       1>&AS_MESSAGE_LOG_FD])
+  then
+    dnl We read out the program interpreter.
+    libc_cv_compiler_dynlinker_default="`$READELF -W -l conftest | grep interpreter | sed -e 's,^.* \(\/.*\).$,\1,g'`"
+    if test -z "$libc_cv_compiler_dynlinker_default"; then
+      dnl Unexpected output and we failed to parse it correctly.
+      libc_cv_compiler_dynlinker_default="UNEXPECTED"
+    fi
+  else
+    dnl Could not determine default dynamic linker used by the compiler.
+    libc_cv_compiler_dynlinker_default="UNKNOWN"
+  fi
+rm -r conftest.*])
+AC_SUBST(libc_cv_compiler_dynlinker_default)
+
 if test "`(cd $srcdir; pwd)`" = "`pwd`"; then
   config_makefile=
 else
===

(c) Detect alternate loader used by compiler.

In ARM's preconfigure we detect that the compiler is using the new
dynamic linker and select the new "armhf" sysdep directory. The
new "armhf" sysdep directory has a shlib-versions file which 
names the dynamic linker correctly.

One downside to this solution is that we need to duplicate
the directory structure for arm along with Implies in order
to pickup the optimized routines normally present.

This is a bit hackish and I'd be open to other solutions, but
at present this works.

2012-04-26  Carlos O'Donell  <carlos_odonell@mentor.com>

	* sysdeps/arm/preconfigure: Select armhf directory based on
	libc_cv_compiler_dynlinker_default.
	* sysdeps/arm/eabi/armhf/shlib-versions: New file.
	* sysdeps/arm/eabi/armhf/armv6t2/Implies: New file.
	* sysdeps/arm/eabi/armhf/armv7/Implies: New file.

Index: sysdeps/arm/preconfigure
===================================================================
--- sysdeps/arm/preconfigure	(revision 368507)
+++ sysdeps/arm/preconfigure	(working copy)
@@ -35,6 +35,19 @@
 		  ;;
 		esac
 
+		# We need to additionally check to see if the compiler
+		# is using the new dynamic linker name for the -mfloat-abi=hard
+		# ABI. If it is then we need to select an alternate directory
+		# with an alternate shlib-versions file which names the dynamic
+		# linker correctly.
+		armhf_dynamic_linker="ld-linux-armhf.so.3"
+                if `echo "$libc_cv_compiler_dynlinker_default" | grep "$armhf_dynamic_linker" >& /dev/null`; then
+		    echo "Found compiler is using the new dynamic linker name for the hard-float ABI."
+		    machine=armhf/$machine
+                else
+		    echo "Found compiler either didn't select hard-float ABI or is using the old dynamic linker name."
+		fi
+
 		machine=arm/eabi/$machine
 		if [ "${CFLAGS+set}" != "set" ]; then
 		  CFLAGS="-g -O2"
Index: sysdeps/arm/eabi/armhf/armv6t2/Implies
===================================================================
--- sysdeps/arm/eabi/armhf/armv6t2/Implies	(revision 0)
+++ sysdeps/arm/eabi/armhf/armv6t2/Implies	(revision 0)
@@ -0,0 +1 @@
+arm/eabi/armv6t2
Index: sysdeps/arm/eabi/armhf/shlib-versions
===================================================================
--- sysdeps/arm/eabi/armhf/shlib-versions	(revision 0)
+++ sysdeps/arm/eabi/armhf/shlib-versions	(revision 0)
@@ -0,0 +1,5 @@
+# As of 2.16 the -mfloat-abi=hard ABI variant has a new unique
+# name for the dynamic loader.
+arm.*-.*-linux-gnueabi.*	DEFAULT			GLIBC_2.4
+
+arm.*-.*-linux-gnueabi.*	ld=ld-linux-armhf.so.3
Index: sysdeps/arm/eabi/armhf/armv7/Implies
===================================================================
--- sysdeps/arm/eabi/armhf/armv7/Implies	(revision 0)
+++ sysdeps/arm/eabi/armhf/armv7/Implies	(revision 0)
@@ -0,0 +1 @@
+arm/eabi/armv7
===

Testing still in progress across the 9 multilibs we build
for Sourcery CodeBench.

I caught a couple of problems early and fixed them though,
like not using AC_MSG_ERROR for the configure failure cases
because you might be installing headers and not have a compiler
capable of compiling an application yet. This does imply that
you *might* not get the right set of headers if such headers
changed depending on the dynamic linker selected (which
they shouldn't).

Comments?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

> 	* configure.in: Check and set libc_cv_compiler_dynlinker_default.

Since this is not used generically, it doesn't belong in the main configure.
Instead, put it in a macro in aclocal.m4 and use it in arm/preconfigure.in.

> +dnl Determine the dynamic linker that the compiler would have used given
> +dnl options we have been given. This is useful for machines to know so

Two spaces between sentences.

> +dnl compute it here and have it available for things like ABI checking.
> +AC_CACHE_CHECK([what dynamic linker is used by the compiler], libc_cv_complier_dynlinker_default,

Line too long, wrap the second arg to below [.

> +[libc_cv_compiler_dynlinker_default=""
> +cat > conftest.c <<EOF
> +int main (void) {}
> +EOF
> +  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS

Why can't use use AC_TRY_LINK?

> +    libc_cv_compiler_dynlinker_default="`$READELF -W -l conftest | grep interpreter | sed -e 's,^.* \(\/.*\).$,\1,g'`"

Don't use grep.  You can use:

	| sed -n 's/^.*interpreter: \(.*\)\@:>@$/\1/p'

> +rm -r conftest.*])

You meant -f.  But you should just leave it to AC_TRY_LINK to clean up.

> In ARM's preconfigure we detect that the compiler is using the new
> dynamic linker and select the new "armhf" sysdep directory. The
> new "armhf" sysdep directory has a shlib-versions file which 
> names the dynamic linker correctly.
> 
> One downside to this solution is that we need to duplicate
> the directory structure for arm along with Implies in order
> to pickup the optimized routines normally present.
> 
> This is a bit hackish and I'd be open to other solutions, but
> at present this works.

I think you can just do the whole check in sysdeps/arm/configure
instead of preconfigure.  Make it AC_DEFINE something.  Then use
%ifdef something in sysdeps/arm/shlib-versions.  Or if you really
want to be open to randomness from the compiler config, you could
even AC_DEFINE_UNQUOTED(FOO, $libc_cv_compiler_dynlinker_default)
and then put in sysdeps/arm/shlib-versions:

arm.*-.*-linux-gnueabi.*	ld=FOO

But I wouldn't recommend that lack of sanity-checking.


Thanks,
Roland

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Thu, 26 Apr 2012, Carlos O'Donell wrote:

> (b) Detect dynamic linker used by compiler.
> 
> The following new configure test detects the dynamic linker
> used by the compiler given the current set of options.
> We store the result in libc_cv_compiler_dynlinker_default
> for later use in ARM's preconfigure.

This is far too complicated.  GCC isn't detecting what dynamic linker 
glibc has, after all.  We should simply test if the compiler predefines 
__ARM_PCS_VFP, which is easy to do in the ARM preconfigure.

> I caught a couple of problems early and fixed them though,
> like not using AC_MSG_ERROR for the configure failure cases
> because you might be installing headers and not have a compiler
> capable of compiling an application yet. This does imply that
> you *might* not get the right set of headers if such headers
> changed depending on the dynamic linker selected (which
> they shouldn't).
> 
> Comments?

It shouldn't (ideally) be necessary to configure glibc, or GCC, more than 
once when bootstrapping.  See Roland's comments at 
<http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>.  That means 
we don't want any configure tests that will give the wrong results in a 
bootstrap configuration (where you don't have a preexisting libc so can't 
link things using it) - where there are existing tests we should remove 
them, and we should avoid adding more.

Testing preprocessor defines is safe.  Linking without -nostdlib isn't 
safe in configure tests.  While it looks like GCC will still pass the 
default -dynamic-linker option to ld when using -nostdlib, I don't think 
you should really rely on that either.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

> This is far too complicated.  GCC isn't detecting what dynamic linker 
> glibc has, after all.  We should simply test if the compiler predefines 
> __ARM_PCS_VFP, which is easy to do in the ARM preconfigure.

Then you don't even need to do any configure stuff.
Just use %ifdef in shlib-versions.


Thanks,
Roland

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 888 bytes --]

On Thursday 26 April 2012 17:09:36 Carlos O'Donell wrote:
> --- sysdeps/arm/preconfigure	(revision 368507)
> +++ sysdeps/arm/preconfigure	(working copy)
> 
> +		armhf_dynamic_linker="ld-linux-armhf.so.3"
> +                if `echo "$libc_cv_compiler_dynlinker_default" | grep
> "$armhf_dynamic_linker" >& /dev/null`; then

not that it matters as it sounds like this is going to be rewritten, but 
there's no need for grep here.  you can use a case statement:
	case $libc_cv_compiler_dynlinker_default in
	*$armhf_dynamic_linker*)
		... hard float ...
		;;
	*)
		... soft float ...
		;;
	esac

also, what's with the back ticks ?  i think you just wanted:
	if echo ... | grep ... ; then
rather than:
	if `echo ... | grep ...` ; then

and you don't want to use ">&" like that ... it's a bashism.  `grep -q` would 
be better, or the POSIX ">/dev/null 2>&1".
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Thu, Apr 26, 2012 at 10:19 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 26 April 2012 17:09:36 Carlos O'Donell wrote:
>> --- sysdeps/arm/preconfigure  (revision 368507)
>> +++ sysdeps/arm/preconfigure  (working copy)
>>
>> +             armhf_dynamic_linker="ld-linux-armhf.so.3"
>> +                if `echo "$libc_cv_compiler_dynlinker_default" | grep
>> "$armhf_dynamic_linker" >& /dev/null`; then
>
> not that it matters as it sounds like this is going to be rewritten, but
> there's no need for grep here.  you can use a case statement:

I always appreciate a good review!

>        case $libc_cv_compiler_dynlinker_default in
>        *$armhf_dynamic_linker*)
>                ... hard float ...
>                ;;
>        *)
>                ... soft float ...
>                ;;
>        esac

Thank's that's a great idea, I always forget case can emulate grep.

> also, what's with the back ticks ?  i think you just wanted:
>        if echo ... | grep ... ; then
> rather than:
>        if `echo ... | grep ...` ; then

WIP, it used to be on separate line and I didn't remove the backticks.

To be pedantic (and POSIX) one would need to use a lot more code to
ensure any command in a pipe sequence exited with the correct status.
I'm assuming echo doesn't fail ;-)

> and you don't want to use ">&" like that ... it's a bashism.  `grep -q` would
> be better, or the POSIX ">/dev/null 2>&1".

Yup, good catch, I always forget ">&" is bash.

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2012 03:03 PM, Joseph S. Myers wrote:
> On Thu, 26 Apr 2012, Carlos O'Donell wrote:
> 
>> (b) Detect dynamic linker used by compiler.
>> 
>> The following new configure test detects the dynamic linker used
>> by the compiler given the current set of options. We store the
>> result in libc_cv_compiler_dynlinker_default for later use in
>> ARM's preconfigure.
> 
> This is far too complicated.  GCC isn't detecting what dynamic
> linker glibc has, after all.  We should simply test if the compiler
> predefines __ARM_PCS_VFP, which is easy to do in the ARM
> preconfigure.
> 
>> I caught a couple of problems early and fixed them though, like
>> not using AC_MSG_ERROR for the configure failure cases because
>> you might be installing headers and not have a compiler capable
>> of compiling an application yet. This does imply that you *might*
>> not get the right set of headers if such headers changed
>> depending on the dynamic linker selected (which they shouldn't).
>> 
>> Comments?
> 
> It shouldn't (ideally) be necessary to configure glibc, or GCC,
> more than once when bootstrapping.  See Roland's comments at 
> <http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>.  That
> means we don't want any configure tests that will give the wrong
> results in a bootstrap configuration (where you don't have a
> preexisting libc so can't link things using it) - where there are
> existing tests we should remove them, and we should avoid adding
> more.
> 
> Testing preprocessor defines is safe.  Linking without -nostdlib
> isn't safe in configure tests.  While it looks like GCC will still
> pass the default -dynamic-linker option to ld when using -nostdlib,
> I don't think you should really rely on that either.
> 

I have the following patch which is based on Carlos's work and
Joseph's suggestion

Thanks

- -Khem

glibc-2.15

2012-04-30  Carlos O'Donell  <carlos_odonell@mentor.com>
	    Khem Raj <raj.khem@gmail.com>

	* sysdeps/arm/preconfigure: Select armhf based on __ARM_PCS_VFP
	compiler predefine.
	* sysdeps/arm/eabi/armhf/shlib-versions: New file.
	* sysdeps/arm/eabi/armhf/armv6t2/Implies: New file.
	* sysdeps/arm/eabi/armhf/armv7/Implies: New file.



glibc-trunk


2012-04-30  Carlos O'Donell  <carlos_odonell@mentor.com>
	    Khem Raj <raj.khem@gmail.com>

	* sysdeps/arm/preconfigure: Select armhf based on __ARM_PCS_VFP
	compiler predefine.
	* sysdeps/arm/armhf/shlib-versions: New file.
	* sysdeps/arm/armhf/armv6t2/Implies: New file.
	* sysdeps/arm/armhf/armv7/Implies: New file.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+favgACgkQuwUzVZGdMxSjrwCfZF3udfIe4OzFCewKRDTzcAdY
+FgAoI/k+zEZPxVquFoK62cSYTOqMK9j
=qJbN
-----END PGP SIGNATURE-----

[-- Attachment #2: arm-hf-loader-2.15.patch --]
[-- Type: text/x-diff, Size: 1756 bytes --]

Index: libc/ports/sysdeps/arm/eabi/armhf/armv6t2/Implies
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ libc/ports/sysdeps/arm/eabi/armhf/armv6t2/Implies	2012-04-30 20:27:01.788730633 -0700
@@ -0,0 +1 @@
+arm/eabi/armv6t2
Index: libc/ports/sysdeps/arm/eabi/armhf/armv7/Implies
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ libc/ports/sysdeps/arm/eabi/armhf/armv7/Implies	2012-04-30 20:26:37.332729450 -0700
@@ -0,0 +1 @@
+arm/eabi/armv7
Index: libc/ports/sysdeps/arm/eabi/armhf/shlib-versions
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ libc/ports/sysdeps/arm/eabi/armhf/shlib-versions	2012-04-30 20:28:01.764733536 -0700
@@ -0,0 +1,6 @@
+# As of 2.16 the -mfloat-abi=hard ABI variant has a new unique
+# name for the dynamic loader.
+arm.*-.*-linux-gnueabi.*	DEFAULT			GLIBC_2.4
+
+arm.*-.*-linux-gnueabi.*	ld=ld-linux-armhf.so.3
+
Index: libc/ports/sysdeps/arm/preconfigure
===================================================================
--- libc.orig/ports/sysdeps/arm/preconfigure	2012-04-30 20:23:20.032719900 -0700
+++ libc/ports/sysdeps/arm/preconfigure	2012-04-30 20:24:34.948723526 -0700
@@ -35,6 +35,19 @@
 		  ;;
 		esac
 
+		archcppflag=`echo "" |
+		$CC $CFLAGS $CPPFLAGS -E -dM - |
+		  grep __ARM_PCS_VFP |
+		  sed -e 's/^#define //' -e 's/ .*//'`
+		case x$archcppflag in
+		x__ARM_PCS_VFP)
+		  echo "Found compiler is configured for ARM hard-float ABI"
+		  machine=armhf/$machine
+		  ;;
+		*)
+		  ;;
+		esac
+
 		machine=arm/eabi/$machine
 		if [ "${CFLAGS+set}" != "set" ]; then
 		  CFLAGS="-g -O2"

[-- Attachment #3: arm-hf-loader-trunk.patch --]
[-- Type: text/x-diff, Size: 1485 bytes --]

Index: arm/armhf/armv7/Implies
===================================================================
--- arm/armhf/armv7/Implies	(revision 0)
+++ arm/armhf/armv7/Implies	(revision 0)
@@ -0,0 +1 @@
+arm/armv7
Index: arm/armhf/armv6t2/Implies
===================================================================
--- arm/armhf/armv6t2/Implies	(revision 0)
+++ arm/armhf/armv6t2/Implies	(revision 0)
@@ -0,0 +1 @@
+arm/armv6t2
Index: arm/armhf/shlib-versions
===================================================================
--- arm/armhf/shlib-versions	(revision 0)
+++ arm/armhf/shlib-versions	(revision 0)
@@ -0,0 +1,6 @@
+# As of 2.16 the -mfloat-abi=hard ABI variant has a new unique
+# name for the dynamic loader.
+arm.*-.*-linux-gnueabi.*	DEFAULT			GLIBC_2.4
+
+arm.*-.*-linux-gnueabi.*	ld=ld-linux-armhf.so.3
+
Index: arm/preconfigure
===================================================================
--- arm/preconfigure	(revision 18306)
+++ arm/preconfigure	(working copy)
@@ -34,7 +34,18 @@
 		  echo 2>&1 "arm/preconfigure: Did not find ARM architecture type; using default"
 		  ;;
 		esac
-
+		archcppflag=`echo "" |
+		$CC $CFLAGS $CPPFLAGS -E -dM - |
+		  grep __ARM_PCS_VFP |
+		  sed -e 's/^#define //' -e 's/ .*//'`
+		case x$archcppflag in
+		x__ARM_PCS_VFP)
+		  echo "Found compiler is configured for ARM hard-float ABI"
+		  machine=armhf/$machine
+		  ;;
+		*)
+		  ;;
+		esac
 		machine=arm/$machine
 		if [ "${CFLAGS+set}" != "set" ]; then
 		  CFLAGS="-g -O2"

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Mon, 30 Apr 2012, Khem Raj wrote:

> I have the following patch which is based on Carlos's work and
> Joseph's suggestion

See Roland's observation in 
<http://sourceware.org/ml/libc-ports/2012-04/msg00174.html> that it should 
be doable just with %ifdef in shlib-versions, and no configure changes at 
all.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Thu, Apr 26, 2012 at 6:06 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> This is far too complicated.  GCC isn't detecting what dynamic linker
>> glibc has, after all.  We should simply test if the compiler predefines
>> __ARM_PCS_VFP, which is easy to do in the ARM preconfigure.
>
> Then you don't even need to do any configure stuff.
> Just use %ifdef in shlib-versions.

OK, so when you said "use %ifdef" I had no idea what you were talking
about. I looked at how shlib-versions is processed and noticed that it
used one of the implicit rules that ran the contents through the
compiler which simplifies the patch down to:

Index: sysdeps/arm/shlib-versions
===================================================================
--- sysdeps/arm/shlib-versions  (revision 370191)
+++ sysdeps/arm/shlib-versions  (working copy)
@@ -1,4 +1,15 @@
 arm.*-.*-linux-gnueabi.*       DEFAULT                 GLIBC_2.4

+# The EABI-derived hard-float ABI uses a new dynamic linker.
+arm.*-.*-linux-gnueabihf       ld=ld-linux-armhf.so.3
+
+%ifdef __ARM_PCS_VFP
+# The EABI-derived hard-float ABI uses a new dynamic linker.
+arm.*-.*-linux-gnueabi.*       ld=ld-linux-armhf.so.3
+%else
+# The EABI-derived soft-float ABI continues to use ld-linux.so.3.
 arm.*-.*-linux-gnueabi.*       ld=ld-linux.so.3
+%endif
+
+# The legacy ABI, no longer supported, uses ld-linux.so.2.
 arm.*-.*-linux.*       ld=ld-linux.so.2
===

I'm not happy with this patch. I don't like it for the reason that an
old unpatched gcc that still uses /lib/ld-linux.so.3 with a new glibc
produces a glibc with /lib/ld-linux-armhf.so.3 even if the compiler
doesn't. I guess in this case your setup is completely broken and
testing should show you that.

Is it important to support the old gcc + new glibc for the hardfloat use case?

If it's not then the above patch should be all we need.

Comments?

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Sat, 5 May 2012, Carlos O'Donell wrote:

> +# The EABI-derived hard-float ABI uses a new dynamic linker.
> +arm.*-.*-linux-gnueabihf       ld=ld-linux-armhf.so.3

That bit's not needed, because the compiler will define __ARM_PCS_VFP.

> +# The legacy ABI, no longer supported, uses ld-linux.so.2.
>  arm.*-.*-linux.*       ld=ld-linux.so.2

And that is no longer in the current shlib-versions, as old-ABI support 
has been removed.

> I'm not happy with this patch. I don't like it for the reason that an
> old unpatched gcc that still uses /lib/ld-linux.so.3 with a new glibc
> produces a glibc with /lib/ld-linux-armhf.so.3 even if the compiler
> doesn't. I guess in this case your setup is completely broken and
> testing should show you that.
> 
> Is it important to support the old gcc + new glibc for the hardfloat use case?

I don't see it as important.  Given the dynamic linker name change, to 
build / use new glibc you will need to patch your compiler to match if it 
predates the change.  Since we've agreed the ABI change, glibc shouldn't 
try to build for the old incompatible dynamic linker name any more; at 
most there could be detection of unpatched compilers to give an obvious 
error, but I think that's too complicated (given that configure tests 
requiring a previously built libc are to be avoided) to be worthwhile.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Sat, May 5, 2012 at 5:06 PM, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On Thu, Apr 26, 2012 at 6:06 PM, Roland McGrath <roland@hack.frob.com> wrote:
>>> This is far too complicated.  GCC isn't detecting what dynamic linker
>>> glibc has, after all.  We should simply test if the compiler predefines
>>> __ARM_PCS_VFP, which is easy to do in the ARM preconfigure.
>>
>> Then you don't even need to do any configure stuff.
>> Just use %ifdef in shlib-versions.
>
> OK, so when you said "use %ifdef" I had no idea what you were talking
> about. I looked at how shlib-versions is processed and noticed that it
> used one of the implicit rules that ran the contents through the
> compiler which simplifies the patch down to:
>
> Index: sysdeps/arm/shlib-versions
> ===================================================================
> --- sysdeps/arm/shlib-versions  (revision 370191)
> +++ sysdeps/arm/shlib-versions  (working copy)
> @@ -1,4 +1,15 @@
>  arm.*-.*-linux-gnueabi.*       DEFAULT                 GLIBC_2.4
>
> +# The EABI-derived hard-float ABI uses a new dynamic linker.
> +arm.*-.*-linux-gnueabihf       ld=ld-linux-armhf.so.3
> +
> +%ifdef __ARM_PCS_VFP
> +# The EABI-derived hard-float ABI uses a new dynamic linker.
> +arm.*-.*-linux-gnueabi.*       ld=ld-linux-armhf.so.3
> +%else
> +# The EABI-derived soft-float ABI continues to use ld-linux.so.3.
>  arm.*-.*-linux-gnueabi.*       ld=ld-linux.so.3
> +%endif
> +
> +# The legacy ABI, no longer supported, uses ld-linux.so.2.
>  arm.*-.*-linux.*       ld=ld-linux.so.2
> ===

Except that this idea doesn't work because the implicit rule uses
-undef and I didn't notice that.

Therefore __ARM_PCS_VFP is *never* defined.

Thoughts?

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Sat, 5 May 2012, Carlos O'Donell wrote:

> Except that this idea doesn't work because the implicit rule uses
> -undef and I didn't notice that.
> 
> Therefore __ARM_PCS_VFP is *never* defined.
> 
> Thoughts?

That suggests going back to a preconfigure test (testing whether 
__ARM_PCS_VFP is defined) to select appropriate sysdeps directories with 
different shlib-versions files.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Sat, May 5, 2012 at 7:17 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sat, 5 May 2012, Carlos O'Donell wrote:
>
>> Except that this idea doesn't work because the implicit rule uses
>> -undef and I didn't notice that.
>>
>> Therefore __ARM_PCS_VFP is *never* defined.
>>
>> Thoughts?
>
> That suggests going back to a preconfigure test (testing whether
> __ARM_PCS_VFP is defined) to select appropriate sysdeps directories with
> different shlib-versions files.

The maintainability of a %ifdef solution seems far superior.

Not having to duplicate directories with Implies is a win.

What about something like this then?

This is against 2.15, but it would be similar for trunk.

* Define HAVE_ARM_PCS_VFP in config.h.in
* In preconfigure set HAVE_ARM_PCS_VFP if we detect __ARM_PCS_VFP
defined by the compiler.
* The header include/libc-symbols.h includes config.h therefore during
shlib-version processing we have access to all the symbols that were
in config.h
* Thus shlib-version correctly defines the dynamic linker based on
gcc's definition of HAVE_ARM_PCS_VFP.

glibc/

Index: config.h.in
===================================================================
--- config.h.in (revision 370191)
+++ config.h.in (working copy)
@@ -236,4 +236,7 @@

 #define HAVE_REGEX 1

+/* The ARM hard-float ABI is being used.  */
+#undef HAVE_ARM_PCS_VFP
+
 #endif
===

glibc-ports/

Index: sysdeps/arm/preconfigure
===================================================================
--- sysdeps/arm/preconfigure    (revision 370191)
+++ sysdeps/arm/preconfigure    (working copy)
@@ -35,6 +35,24 @@
                  ;;
                esac

+               # We check to see if the compiler and flags are
+               # selecting the hard-float ABI and if they are then
+               # we define ARM_PCS_VFP which is later used by
+               # shlib-versions to select the appropriate name for
+               # the dynamic linker.
+               archcppflag=`echo "" |
+               $CC $CFLAGS $CPPFLAGS -E -dM - |
+                 grep __ARM_PCS_VFP |
+                 sed -e 's/^#define //' -e 's/ .*//'`
+               case x$archcppflag in
+               x__ARM_PCS_VFP)
+                 echo "Found compiler is configured for ARM hard-float ABI"
+                 echo "#define HAVE_ARM_PCS_VFP 1" >> confdefs.h
+                 ;;
+               *)
+                 ;;
+               esac
+
                machine=arm/eabi/$machine
                if [ "${CFLAGS+set}" != "set" ]; then
                  CFLAGS="-g -O2"
Index: sysdeps/arm/shlib-versions
===================================================================
--- sysdeps/arm/shlib-versions  (revision 370191)
+++ sysdeps/arm/shlib-versions  (working copy)
@@ -1,4 +1,12 @@
 arm.*-.*-linux-gnueabi.*       DEFAULT                 GLIBC_2.4

+%ifdef HAVE_ARM_PCS_VFP
+# The EABI-derived hard-float ABI uses a new dynamic linker.
+arm.*-.*-linux-gnueabi.*       ld=ld-linux-armhf.so.3
+%else
+# The EABI-derived soft-float ABI continues to use ld-linux.so.3.
 arm.*-.*-linux-gnueabi.*       ld=ld-linux.so.3
+%endif
+
+# The legacy ABI, no longer supported, uses ld-linux.so.2.
 arm.*-.*-linux.*       ld=ld-linux.so.2
==

I know the ">> confdefs.h" is a bit of hackery, but this solution is
remarkably better than adding a whole new directory level with
Implies.

To tell you the truth at this late hour I can't remember why we're
doing this in preconfigure, why can't this all be in
sysdeps/arm/configure.in where I can use AC_DEFINE?

Comments?

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Sat, 5 May 2012, Carlos O'Donell wrote:

> * Define HAVE_ARM_PCS_VFP in config.h.in

Is there a way we can avoid architecture-specific defines needing to go in 
config.h.in - have architecture-specific files instead that it includes in 
some way?  Does it work for configure.in fragments to use 
AC_CONFIG_HEADERS naming their own config.h.in fragments - will each 
fragment then get the right substitutions made on it?  (A mechanism would 
also be needed for all the fragments to get included automatically - 
probably the main config.h should include all the others.)

(The same issue applies with AC_SUBST as with AC_DEFINE - there shouldn't 
need to be a load of architecture-specific AC_SUBSTs in configure.in and 
config.make.in.  But let's see if it can be solved for config.h.in first.)

> To tell you the truth at this late hour I can't remember why we're
> doing this in preconfigure, why can't this all be in
> sysdeps/arm/configure.in where I can use AC_DEFINE?

preconfigure is only relevant for choosing sysdeps directories.  For 
defining something, sysdeps/arm/configure.in should work.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Sun, May 6, 2012 at 8:13 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sat, 5 May 2012, Carlos O'Donell wrote:
>
>> * Define HAVE_ARM_PCS_VFP in config.h.in
>
> Is there a way we can avoid architecture-specific defines needing to go in
> config.h.in - have architecture-specific files instead that it includes in
> some way?  Does it work for configure.in fragments to use
> AC_CONFIG_HEADERS naming their own config.h.in fragments - will each
> fragment then get the right substitutions made on it?  (A mechanism would
> also be needed for all the fragments to get included automatically -
> probably the main config.h should include all the others.)

I don't think it possible to achieve any of your suggestions without
additional work on the glibc build infrastructure.

I completely agree with you, and such a solution would move the PPC
config.h.in defines into their own fragment, but such work is outside
the scope of the current ARM hard-float dynamic linker change.

> (The same issue applies with AC_SUBST as with AC_DEFINE - there shouldn't
> need to be a load of architecture-specific AC_SUBSTs in configure.in and
> config.make.in.  But let's see if it can be solved for config.h.in first.)

The cleanup of the master config.h.in can be done as a separate step
and should be done with review from other glibc developers and with
more time for review.

We should not block the current inclusion of the ARM glibc changes
which the community is waiting to use.

>> To tell you the truth at this late hour I can't remember why we're
>> doing this in preconfigure, why can't this all be in
>> sysdeps/arm/configure.in where I can use AC_DEFINE?
>
> preconfigure is only relevant for choosing sysdeps directories.  For
> defining something, sysdeps/arm/configure.in should work.

I'll use sysdeps/arm/configure.in and thus avoid the confdefs.h hack
in preconfigure.

I'll post a patch shortly.

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Sun, 6 May 2012, Carlos O'Donell wrote:

> I'll use sysdeps/arm/configure.in and thus avoid the confdefs.h hack
> in preconfigure.
> 
> I'll post a patch shortly.

Please post patches that are against current git sources, not some other 
version.

If the ports patch depends on a libc patch, post the libc patch to 
libc-alpha and I'll await the conclusion of libc-alpha discussions on the 
approach before reviewing the ports patch.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

I trimmed the CC of people probably not very interested in arcane libc
build internals, and added libc-alpha since we're now talking about
possibly changing the generic build infrastructure.

> Except that this idea doesn't work because the implicit rule uses
> -undef and I didn't notice that.
> 
> Therefore __ARM_PCS_VFP is *never* defined.

I don't really recall, but I suspect that the reason for -undef may have
been just the default predefines like "i386" or "linux" causing problems.

Possibly there once was a principle that this mechanism should only be
used for testing things we defined in config.h or other such places
rather than predefines--the same general principle by which we prefer
sysdeps file selection to #ifdef on predefines.  But here we have a case
where using the predefine seems sensible enough.  There's no need to
enforce such a philosophy mechanically so it constrains all cases.  We
can just do it socially through code review, to constrain reliance on
predefines to the very few cases where we really think it's the wise choice.

Just dropping -undef will break things by replacing all "linux" with "1"
and so forth.  In some trivial experiments on my random system version of
GCC, -std=c99 or -std=c89 does not eliminate the nonstandard predefines
(non-__ names), but -ansi does--despite the GCC manual's claim that -ansi
is equivalent to -std=c89.  So we could use -ansi instead of -undef,
though that feels a little icky because it's so nonobvious (and contrary
to documentation) that this is what has that effect.

Conversely, I can see a doing a generalized version of configure-time
tests for predefines.  i.e.
	GLIBC_CHECK_PREDEFINE([__ARM_PCS_VFP])
would expand to a check that adds __ARM_PCS_VFP to an extra config.h-like
file (or maybe just a config.make variable, for simplicity at the cost of
full dependency tracking goodness) if predefined at configure time.


Thanks,
Roland

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Mon, May 7, 2012 at 2:47 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I don't really recall, but I suspect that the reason for -undef may have
> been just the default predefines like "i386" or "linux" causing problems.
>
> Possibly there once was a principle that this mechanism should only be
> used for testing things we defined in config.h or other such places
> rather than predefines--the same general principle by which we prefer
> sysdeps file selection to #ifdef on predefines.  But here we have a case
> where using the predefine seems sensible enough.  There's no need to
> enforce such a philosophy mechanically so it constrains all cases.  We
> can just do it socially through code review, to constrain reliance on
> predefines to the very few cases where we really think it's the wise choice.
>
> Just dropping -undef will break things by replacing all "linux" with "1"
> and so forth.  In some trivial experiments on my random system version of
> GCC, -std=c99 or -std=c89 does not eliminate the nonstandard predefines
> (non-__ names), but -ansi does--despite the GCC manual's claim that -ansi
> is equivalent to -std=c89.  So we could use -ansi instead of -undef,
> though that feels a little icky because it's so nonobvious (and contrary
> to documentation) that this is what has that effect.

Using -ansi instead of -undef seems like a bad idea even if it would
fix the problem at hand.

> Conversely, I can see a doing a generalized version of configure-time
> tests for predefines.  i.e.
>        GLIBC_CHECK_PREDEFINE([__ARM_PCS_VFP])
> would expand to a check that adds __ARM_PCS_VFP to an extra config.h-like
> file (or maybe just a config.make variable, for simplicity at the cost of
> full dependency tracking goodness) if predefined at configure time.

I agree, that sounds like a good solution e.g. a glibc specific macro
that does a little more than AC_EGREP_CPP provides.

For avoidance of doubt I'm not going to go that route for this change,
but I did file a bugzilla ticket to look into a cleanup of
config.in.h.

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Mon, 7 May 2012, Roland McGrath wrote:

> and so forth.  In some trivial experiments on my random system version of
> GCC, -std=c99 or -std=c89 does not eliminate the nonstandard predefines
> (non-__ names), but -ansi does--despite the GCC manual's claim that -ansi

It does for me (well, non-_[_A-Z] names; things such as _LP64 are also in 
the reserved namespace).  There's 
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545> for a limited number of 
cases where such macros are defined from specs (that check textually for 
the -ansi option, instead of for flag_iso as set inside cc1), but the bulk 
of cases of that were fixed long ago.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

> It does for me (well, non-_[_A-Z] names; things such as _LP64 are also in 
> the reserved namespace).  There's 
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545> for a limited number of 
> cases where such macros are defined from specs (that check textually for 
> the -ansi option, instead of for flag_iso as set inside cc1), but the bulk 
> of cases of that were fixed long ago.

What I was using in my earlier experiments was "Ubuntu 4.4.3-4ubuntu5.1" on
x86_64-linux-gnu native.  But I happen to have handy a GCC trunk from last
week sometime built for --target=arm-linux-gnueabi:

	$ ./xgcc -B./ -E -dM -std=c99 -x assembler-with-cpp /dev/null | grep '#define [^_]'
	#define unix 1
	#define linux 1

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

> Using -ansi instead of -undef seems like a bad idea even if it would
> fix the problem at hand.

Please elaborate on your thinking here.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Mon, May 7, 2012 at 3:54 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> Using -ansi instead of -undef seems like a bad idea even if it would
>> fix the problem at hand.
>
> Please elaborate on your thinking here.

We have two possible solutions at hand:

* Use configure/config.h and the implicit rule as-is to solve the
problem using %ifdef HAVE_ARM_PCS_VFP in shlib-deps.

or

* Change the implicit rule to use -ansi and use %ifdef __ARM_PCS_VFP
in shlib-deps.

It's still not clear to me that -ansi is documented as doing what we
want, and therefore I would conservatively select the more easily
understood patch to configure/config.h as opposed to changing `-undef'
for `-ansi' which is a change that could have unforeseen
repercussions.

Cheers,
Carlos.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Carlos O'Donell]

On Mon, May 7, 2012 at 3:59 PM, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On Mon, May 7, 2012 at 3:54 PM, Roland McGrath <roland@hack.frob.com> wrote:
>>> Using -ansi instead of -undef seems like a bad idea even if it would
>>> fix the problem at hand.
>>
>> Please elaborate on your thinking here.
>
> We have two possible solutions at hand:
>
> * Use configure/config.h and the implicit rule as-is to solve the
> problem using %ifdef HAVE_ARM_PCS_VFP in shlib-deps.
>
> or
>
> * Change the implicit rule to use -ansi and use %ifdef __ARM_PCS_VFP
> in shlib-deps.
>
> It's still not clear to me that -ansi is documented as doing what we
> want, and therefore I would conservatively select the more easily
> understood patch to configure/config.h as opposed to changing `-undef'
> for `-ansi' which is a change that could have unforeseen
> repercussions.

s/shlib-deps/shlib-versions/g

c.

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Joseph S. Myers]

On Mon, 7 May 2012, Roland McGrath wrote:

> What I was using in my earlier experiments was "Ubuntu 4.4.3-4ubuntu5.1" on
> x86_64-linux-gnu native.  But I happen to have handy a GCC trunk from last
> week sometime built for --target=arm-linux-gnueabi:
> 
> 	$ ./xgcc -B./ -E -dM -std=c99 -x assembler-with-cpp /dev/null | grep '#define [^_]'

Ah, it appears "-x assembler-with-cpp" is the critical thing here that 
disables -std processing (I don't know why it does so, offhand).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.

[Roland McGrath]

> Ah, it appears "-x assembler-with-cpp" is the critical thing here that 
> disables -std processing (I don't know why it does so, offhand).

Ah, good catch.  That is pretty bizarre.  But for pragmatic issues, I don't
know any reason we especially need -x assembler-with-cpp rather than using
-x c-header or -x c.  The difference seems to be passing -lang-asm along to
cc1, which affects cpp in a few ways that seem unlikely to matter to us.
But I'm not really certain what all the differences might be.

In a quick attempt, the only issue I saw was not having the __ASSEMBLER__
predefine, which makes config.h barf.  But that is easy to resolve.


Thanks,
Roland