Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Alexey Brodkin]

Hi Andreas,

I'm trying to implement multilib support for ARC port of Glibc
and for that we seem to need to have unique slibdir/rtlddir pair per
each machine flavor. In our case these are at least:
 - ARC700 (legacy ARCompact architecture)
 - ARC HS38 (new gen ARCv2 architecture)
 - ARC HS38 with hardware floating-point
 - ARC HS48 (binary-compatible with HS38 but with different pipeline so
             compiler schedules instructions differently)
 - eventually there'll be newer generations like ARCv3/v4 etc

Given we have in GCC a dedicated "-mcpu" value for each of items above
my first thought was to "automatically" setup slibdir/rtlddir
based on "-mcpu" value passed in CC during configuration.

Something like that:
---------------------------------->8------------------------------------
+++ b/sysdeps/unix/sysv/linux/arc/configure.ac
@@ -2,3 +2,10 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 # Local configure fragment for sysdeps/unix/sysv/linux/arc.

 arch_minimum_kernel=3.9.0
+
+# Extract "-mcpu=xxx" value from CC to install libs in a separate folder
+arc_mcpu=[`echo $CC | grep -Po '\-mcpu=\K[^ ]+'`]
+
+if test "$arc_mcpu" != "" ; then
+       LIBC_SLIBDIR_RTLDDIR([lib/${arc_mcpu}], [lib/${arc_mcpu}])
+fi
---------------------------------->8------------------------------------

But apparently that doesn't work due to your change [1] in
commit 128c43a2d630 ("LIBC_SLIBDIR_RTLDDIR: substitute arguments in single quotes").

I guess mentioned change is not supposed to be reverted but then
how do you think it's possible [if at all] to implement that kind of
"automatic" setup of slibdir/rtlddir?

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=128c43a2d630

-Alexey

Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Andreas Schwab]

On Mai 31 2019, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> I guess mentioned change is not supposed to be reverted but then
> how do you think it's possible [if at all] to implement that kind of
> "automatic" setup of slibdir/rtlddir?

As the commit message says, you can reference makefile variables in the
value.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Joseph Myers]

On Fri, 31 May 2019, Alexey Brodkin wrote:

> Hi Andreas,
> 
> I'm trying to implement multilib support for ARC port of Glibc
> and for that we seem to need to have unique slibdir/rtlddir pair per
> each machine flavor. In our case these are at least:
>  - ARC700 (legacy ARCompact architecture)
>  - ARC HS38 (new gen ARCv2 architecture)
>  - ARC HS38 with hardware floating-point
>  - ARC HS48 (binary-compatible with HS38 but with different pipeline so
>              compiler schedules instructions differently)

If two processors are binary-compatible, in general you wouldn't have 
different library directories.  (The HWCAP mechanism can be used to have a 
single dynamic linker search different directories for optimized libraries 
depending on the processor; put the relevant HWCAP bits in 
HWCAP_IMPORTANT.  And of course you can just install different library 
builds depending on the processor you'll be running the resulting OS on.)

Different library directories are intended for the case where binaries for 
different ABIs can be executed on the same system (e.g. 32-bit and 64-bit; 
<https://sourceware.org/ml/libc-alpha/2018-01/msg00008.html> gives more 
details of the various places that need updating to support such a 
configuration in glibc).  For other cases of different ABIs, there should 
be different dynamic linker names, to support multiarch configurations 
that might run different-architecture binaries under emulation, but 
different library directories are not required.

> Given we have in GCC a dedicated "-mcpu" value for each of items above
> my first thought was to "automatically" setup slibdir/rtlddir
> based on "-mcpu" value passed in CC during configuration.

Checking -mcpu in CC is a bad idea, given that the compiler might have 
been configured with a default CPU rather than passing it on the command 
line.

Rather, you should test how the compiler behaves: either run $CC $CFLAGS 
$CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros, 
or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose.  (If you 
don't have predefined macros that make all the required ABI distinctions, 
obviously you need to add them.)  There are various examples of this in 
existing configure / preconfigure fragments.

Since there should be a finite list of known ABIs (which would be listed 
on <https://sourceware.org/glibc/wiki/ABIList> for a port included in 
glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in 
a case statement.

-- 
Joseph S. Myers
joseph at codesourcery.com

Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Alexey Brodkin]

Hi Joseph,

> -----Original Message-----
> From: Joseph Myers <joseph at codesourcery.com>
> Sent: Monday, June 3, 2019 6:41 PM
> To: Alexey Brodkin <abrodkin at synopsys.com>
> Cc: Andreas Schwab <schwab at suse.de>; libc-alpha at sourceware.org; linux-snps-arc at lists.infradead.org
> Subject: Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
> 
> On Fri, 31 May 2019, Alexey Brodkin wrote:
> 
> > Hi Andreas,
> >
> > I'm trying to implement multilib support for ARC port of Glibc
> > and for that we seem to need to have unique slibdir/rtlddir pair per
> > each machine flavor. In our case these are at least:
> >  - ARC700 (legacy ARCompact architecture)
> >  - ARC HS38 (new gen ARCv2 architecture)
> >  - ARC HS38 with hardware floating-point
> >  - ARC HS48 (binary-compatible with HS38 but with different pipeline so
> >              compiler schedules instructions differently)
> 
> If two processors are binary-compatible, in general you wouldn't have
> different library directories.  (The HWCAP mechanism can be used to have a
> single dynamic linker search different directories for optimized libraries
> depending on the processor; put the relevant HWCAP bits in
> HWCAP_IMPORTANT.  And of course you can just install different library
> builds depending on the processor you'll be running the resulting OS on.)
> 
> Different library directories are intended for the case where binaries for
> different ABIs can be executed on the same system (e.g. 32-bit and 64-bit;
> https://sourceware.org/ml/libc-alpha/2018-01/msg00008.html gives more
> details of the various places that need updating to support such a
> configuration in glibc).  For other cases of different ABIs, there should
> be different dynamic linker names, to support multiarch configurations
> that might run different-architecture binaries under emulation, but
> different library directories are not required.

Well I'm trying to solve a little bit different problem - to build
a universal multilib cross-toolchain which will be usable for building
binaries optimized for different ARC cores. Different I mean:
 - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 32-bit)
 - Hard/soft floating-point
 - etc.

GCC itself handles multilib perfectly fine as long as C library components
are installed in proper locations. And bare-metal toolchain with Newlib as
well as uClibc Linux toolchain are known to work as expected: C libraries
get installed to a subfolder referenced by "arc-linux-gcc -print-multi-lib".

As for Glibc at least in Crosstool-NG (the one and only toolchain builder
that supports multilib toolchains) Glibc's smarts are used for libs installation
in sysroot.

I think it used to be done similarly to Newlib & uClibc but then was
converted to a current state by this commit:
https://github.com/crosstool-ng/crosstool-ng/commit/43c303c946c61469181d633cd5620cb92e44c329

That said since I'm not yet interested in multiple libs on target
maybe I'm just looking at a wrong place and instead CT-NG should be
improved. Alexey Neyman (in CC) might have more to add here.

> > Given we have in GCC a dedicated "-mcpu" value for each of items above
> > my first thought was to "automatically" setup slibdir/rtlddir
> > based on "-mcpu" value passed in CC during configuration.
> 
> Checking -mcpu in CC is a bad idea, given that the compiler might have
> been configured with a default CPU rather than passing it on the command
> line.

Well this case (no "-mcpu" in CC) is handled - then we just installed
libs in default non-multilib location, i.e. simple "/lib".
 
> Rather, you should test how the compiler behaves: either run $CC $CFLAGS
> $CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros,
> or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose.  (If you
> don't have predefined macros that make all the required ABI distinctions,
> obviously you need to add them.)  There are various examples of this in
> existing configure / preconfigure fragments.

Right I did see a lot of those.

> Since there should be a finite list of known ABIs (which would be listed
> on https://sourceware.org/glibc/wiki/ABIList for a port included in
> glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in
> a case statement.

Agree, but again this is more for run-time libs on target where having
many flavors of libs is quite an overkill.

-Alexey
 

Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Joseph Myers]

On Mon, 3 Jun 2019, Alexey Brodkin wrote:

> Well I'm trying to solve a little bit different problem - to build
> a universal multilib cross-toolchain which will be usable for building
> binaries optimized for different ARC cores. Different I mean:
>  - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 32-bit)
>  - Hard/soft floating-point
>  - etc.

That sort of thing generally uses a separate sysroot for each multilib.  
(Using GCC's t-sysroot-suffix avoids needing to define SYSROOT_SUFFIX_SPEC 
manually yourself.)

Then the libraries don't need to use separate library directories if only 
one ABI makes sense on a target at a time.  (But cases with different 
endianness / different function calling ABI / different struct layout etc. 
should still use different dynamic linker names.)

> > Checking -mcpu in CC is a bad idea, given that the compiler might have
> > been configured with a default CPU rather than passing it on the command
> > line.
> 
> Well this case (no "-mcpu" in CC) is handled - then we just installed
> libs in default non-multilib location, i.e. simple "/lib".

The locations should be a function of the ABI - *not* of whether the ABI 
is the default one for the compiler.  (For example, /lib64 is the 
directory for non-x32 x86_64 libraries - both in an x86_64-linux-gnu 
toolchain, and also for the -m64 multilib of an i686-linux-gnu toolchain 
configured --enable-targets=all.  If you use Debian-style multiarch 
layout, the locations are still a function of the ABI, just a different 
function.)

-- 
Joseph S. Myers
joseph at codesourcery.com