[committed] aarch64: Always use .init/.fini_array for GNU/Linux

I was wondering why the (now fixed) c-c++-common/attr-retain-[78].c
failures were showing up in the native results for aarch64-linux-gnu
but not in the posted cross results.  It turns out that .init/
.fini_array support is disabled by default for cross builds,
which in turn stops those tests from running.

The test for .init/fini_array support has two parts: one that builds
something with the assembler and linker, and another that compiles
C code and uses preprocessor macros to test the glibc version.
The first test would work with build=host but the second is only
safe for build=target.

However, AArch64 postdates glibc and binutils support for
.init/fini_array by some distance, so it's safe to hard-code the
result to "yes" for cross compilers.

This fixes the only material difference in auto-host.h between
a native and a cross build.

Tested on aarch64-linux-gnu, pushed to trunk.

Richard


gcc/
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): When cross-compiling,
	default to yes for aarch64-linux-gnu.
	* configure: Regenerate.
---
 gcc/acinclude.m4 | 14 ++++++++++++--
 gcc/configure    | 14 ++++++++++++--
 2 files changed, 24 insertions(+), 4 deletions(-)

On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:

> However, AArch64 postdates glibc and binutils support for
> .init/fini_array by some distance, so it's safe to hard-code the
> result to "yes" for cross compilers.

Should there be an automatism for any other new architecture added?

Andreas.

On Wed, 21 Apr 2021, Andreas Schwab wrote:

> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
> 
> > However, AArch64 postdates glibc and binutils support for
> > .init/fini_array by some distance, so it's safe to hard-code the
> > result to "yes" for cross compilers.
> 
> Should there be an automatism for any other new architecture added?

See what I said in 
<https://sourceware.org/pipermail/libc-alpha/2018-November/098712.html>.  
I think the configure test is valid for cross compilation and doesn't need 
to check build = host = target at all.

Joseph Myers <joseph@codesourcery.com> writes:
> On Wed, 21 Apr 2021, Andreas Schwab wrote:
>
>> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
>> 
>> > However, AArch64 postdates glibc and binutils support for
>> > .init/fini_array by some distance, so it's safe to hard-code the
>> > result to "yes" for cross compilers.
>> 
>> Should there be an automatism for any other new architecture added?

I guess it depends on whether we want this to be done automatically
only for GNU/Linux or for other OSes too.  I'm a bit nervous about
enabling it for aarch64*-elf by default.

I guess we could have:

    x86_64*-linux-gnu)
    ...all other current linux-gnu targets except aarch64....
    ...
      ...=no
      ;;

    *-*-linux-gnu*)
      ...=yes
      ;;

    *)
      ...=no
      ;;

Then other targets that are similarly “new enough” can be removed
from the first list.  New architectures would automatically be “yes”.

> See what I said in 
> <https://sourceware.org/pipermail/libc-alpha/2018-November/098712.html>.  
> I think the configure test is valid for cross compilation and doesn't need 
> to check build = host = target at all.

Are you sure?  The default (non-ia64) case includes:

	AC_PREPROC_IFELSE([AC_LANG_SOURCE([
#ifndef __ELF__
# error Not an ELF OS
#endif
#include <stdlib.h>
#if defined __GLIBC_PREREQ
# if __GLIBC_PREREQ (2, 4)
# else
#  error GLIBC 2.4 required
# endif
#else
# if defined __sun__ && defined __svr4__
   /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8.  */
# else
#  error The C library not known to support .init_array/.fini_array
# endif
#endif
])],, [gcc_cv_initfini_array=no]);;

which AFAICT would test preprocessing for the host rather than the target.

Thanks,
Richard

On Wed, 21 Apr 2021, Richard Sandiford wrote:

> which AFAICT would test preprocessing for the host rather than the target.

Ah, good point.  (GCC_GLIBC_VERSION_GTE_IFELSE can be used to deal with 
glibc version conditionals in a way that works, given appropriate 
configure options, even when the target headers aren't available, though 
at present the gcc_AC_INITFINI_ARRAY call comes before the glibc version 
information has been computed.)