Patchwork build-many-glibcs.py question (updating for multilibs on aarch64)

login
register
mail settings
Submitter Steve Ellcey
Date Dec. 12, 2016, 10:02 p.m.
Message ID <201612122202.uBCM2JuU006047@sellcey-lt.caveonetworks.com>
Download mbox | patch
Permalink /patch/18416/
State New
Headers show

Comments

Steve Ellcey - Dec. 12, 2016, 10:02 p.m.
I am trying to update build-many-glibcs.py to build ILP32 variations of
the aarch64 glibc library.  I have my glibc patches applied and linux
sources with the ILP32 patches and I have added this patch to
build-many-glibcs.py:



Do those changes look right?

My ILP32 glibc build is failing because it is building lib-names-lp64.h instead
of lib-names-ilp32.h.  I am having trouble figuring out why the glibc make is
building the LP64 header instead of the ILP32 one.

I looked at the initial compiler build and it seems fine, it supports
the ilp32 and lp64 abis.  The glibc configure looks OK, with:

	/home/ubuntu/sellcey/build-many/build/compilers/aarch64-linux-gnu/glibc-src/aarch64-linux-gnu-ilp32/configure '--prefix=/usr' --enable-add-ons '--build=aarch64-unknown-linux-gnu' '--host=aarch64-glibc-linux-gnu' 'CC=aarch64-glibc-linux-gnu-gcc -mabi=ilp32' 'CXX=aarch64-glibc-linux-gnu-g++ -mabi=ilp32' 'AR=aarch64-glibc-linux-gnu-ar' 'AS=aarch64-glibc-linux-gnu-as' 'LD=aarch64-glibc-linux-gnu-ld' 'NM=aarch64-glibc-linux-gnu-nm' 'OBJCOPY=aarch64-glibc-linux-gnu-objcopy' 'OBJDUMP=aarch64-glibc-linux-gnu-objdump' 'RANLIB=aarch64-glibc-linux-gnu-ranlib' 'READELF=aarch64-glibc-linux-gnu-readelf' 'STRIP=aarch64-glibc-linux-gnu-strip'

But the actual build dies with:

	In file included from ../sysdeps/gnu/unwind-resume.c:22:0:
	/home/ubuntu/sellcey/build-many/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu-ilp32/gnu/lib-names.h:16:34: fatal error: gnu/lib-names-ilp32.h: No such file or directory
 	# include <gnu/lib-names-ilp32.h>
                                  ^
	compilation terminated.


Because the build directory has lib-names-lp64.h instead of lib-names-ilp32.h
and unwind-resume.c is (properly) being compiled with -mabi=ilp32.

Any ideas on what to check?  sysdeps/unix/sysv/linux/aarch64/Makefile does
have all the variants listed:

	abi-variants := lp64
	abi-variants += lp64_be
	abi-variants += ilp32
	abi-variants += ilp32_be

	ifeq (,$(filter $(default-abi),$(abi-variants)))
	Unknown ABI, must be one of $(abi-variants)
	endif

	abi-lp64-options := -U__AARCH64EB__ -D__LP64__ -U__ILP32__
	abi-lp64-condition := __WORDSIZE == 64 && !defined __AARCH64EB__

	abi-lp64_be-options := -D__AARCH64EB__ -D__LP64__ -U__ILP32__
	abi-lp64_be-condition := __WORDSIZE == 64 && defined __AARCH64EB__

	abi-ilp32-options := -U__AARCH64EB__ -U__LP64__ -D__ILP32__
	abi-ilp32-condition := __WORDSIZE == 32 && !defined __AARCH64EB__

	abi-ilp32_be-options := -D__AARCH64EB__ -U__LP64__ -D__ILP32__
	abi-ilp32_be-condition := __WORDSIZE == 32 && defined __AARCH64EB__

Steve Ellcey
sellcey@caviumnetworks.com
Andreas Schwab - Dec. 12, 2016, 10:23 p.m.
On Dez 12 2016, Steve Ellcey <sellcey@cavium.com> wrote:

> My ILP32 glibc build is failing because it is building lib-names-lp64.h instead
> of lib-names-ilp32.h.  I am having trouble figuring out why the glibc make is
> building the LP64 header instead of the ILP32 one.
>
> I looked at the initial compiler build and it seems fine, it supports
> the ilp32 and lp64 abis.  The glibc configure looks OK, with:
>
> 	/home/ubuntu/sellcey/build-many/build/compilers/aarch64-linux-gnu/glibc-src/aarch64-linux-gnu-ilp32/configure '--prefix=/usr' --enable-add-ons '--build=aarch64-unknown-linux-gnu' '--host=aarch64-glibc-linux-gnu' 'CC=aarch64-glibc-linux-gnu-gcc -mabi=ilp32' 'CXX=aarch64-glibc-linux-gnu-g++ -mabi=ilp32' 'AR=aarch64-glibc-linux-gnu-ar' 'AS=aarch64-glibc-linux-gnu-as' 'LD=aarch64-glibc-linux-gnu-ld' 'NM=aarch64-glibc-linux-gnu-nm' 'OBJCOPY=aarch64-glibc-linux-gnu-objcopy' 'OBJDUMP=aarch64-glibc-linux-gnu-objdump' 'RANLIB=aarch64-glibc-linux-gnu-ranlib' 'READELF=aarch64-glibc-linux-gnu-readelf' 'STRIP=aarch64-glibc-linux-gnu-strip'

Probably you didn't install the patched kernel uapi headers in the
sysroot.

Andreas.
Steve Ellcey - Dec. 12, 2016, 10:57 p.m.
On Mon, 2016-12-12 at 23:23 +0100, Andreas Schwab wrote:

> Probably you didn't install the patched kernel uapi headers in the
> sysroot.
> 
> Andreas.

No, I have a patched kernel tree.  I think I have found the problem, I
updated the glibc source tree with my ILP32 patches but the patches
don't include configure, just configure.ac, and I didn't regenerate the
configure files in the build tree I am using to test my build-many-
glibcs.py changes.  This in turn gave me the wrong value for default-
abi variable in Makerules.

Steve Ellcey
sellcey@caviumnetworks.com
Joseph Myers - Dec. 12, 2016, 11:18 p.m.
On Mon, 12 Dec 2016, Steve Ellcey wrote:

> @@ -126,9 +126,15 @@ class Context(object):
>          no_isolate = ('-fno-isolate-erroneous-paths-dereference'
>                        ' -fno-isolate-erroneous-paths-attribute')
>          self.add_config(arch='aarch64',
> -                        os_name='linux-gnu')
> +                        os_name='linux-gnu',
> +                        gcc_cfg=['--with-multilib-list=lp64,ilp32'],
> +                        glibcs=[{},
> +                                {'variant': 'ilp32', 'ccopts': '-mabi=ilp32'}])
>          self.add_config(arch='aarch64_be',
> -                        os_name='linux-gnu')
> +                        os_name='linux-gnu',
> +                        gcc_cfg=['--with-multilib-list=lp64,ilp32'],
> +                        glibcs=[{},
> +                                {'variant': 'ilp32', 'ccopts': '-mabi=ilp32'}])

Although building a multilib GCC is logically correct, it's probably not a 
good idea until the stable GCC, binutils and Linux kernel versions used in 
build-many-glibcs.py all have the required support for ILP32, as including 
ILP32 glibc in the same GCC build as LP64 would lose LP64 testing if 
missing kernel headers support for ILP32 results in the ILP32 build 
failing.

Thus, if missing kernel headers support makes the ILP32 build fail, the 
compiler builds for ILP32 should be kept separate until the ILP32 kernel 
headers support is in an actual kernel release, which is used by 
build-many-glibcs.py.
Steve Ellcey - Dec. 12, 2016, 11:26 p.m.
On Mon, 2016-12-12 at 23:18 +0000, Joseph Myers wrote:
> On Mon, 12 Dec 2016, Steve Ellcey wrote:
> 
> > 
> > @@ -126,9 +126,15 @@ class Context(object):
> >          no_isolate = ('-fno-isolate-erroneous-paths-dereference'
> >                        ' -fno-isolate-erroneous-paths-attribute')
> >          self.add_config(arch='aarch64',
> > -                        os_name='linux-gnu')
> > +                        os_name='linux-gnu',
> > +                        gcc_cfg=['--with-multilib-
> > list=lp64,ilp32'],
> > +                        glibcs=[{},
> > +                                {'variant': 'ilp32', 'ccopts': '-
> > mabi=ilp32'}])
> >          self.add_config(arch='aarch64_be',
> > -                        os_name='linux-gnu')
> > +                        os_name='linux-gnu',
> > +                        gcc_cfg=['--with-multilib-
> > list=lp64,ilp32'],
> > +                        glibcs=[{},
> > +                                {'variant': 'ilp32', 'ccopts': '-
> > mabi=ilp32'}])
> Although building a multilib GCC is logically correct, it's probably not a 
> good idea until the stable GCC, binutils and Linux kernel versions used in 
> build-many-glibcs.py all have the required support for ILP32, as including 
> ILP32 glibc in the same GCC build as LP64 would lose LP64 testing if 
> missing kernel headers support for ILP32 results in the ILP32 build 
> failing.
> 
> Thus, if missing kernel headers support makes the ILP32 build fail, the 
> compiler builds for ILP32 should be kept separate until the ILP32 kernel 
> headers support is in an actual kernel release, which is used by 
> build-many-glibcs.py.

That seems reasonable.  What arch names would you suggest for the ILP32
builds?  I would probably go with aarch64_ilp32 and aarch32_be_ilp32
unless there was a reason to use something else.

Steve Ellcey
sellcey@caviumnetworks.com
Joseph Myers - Dec. 12, 2016, 11:57 p.m.
On Mon, 12 Dec 2016, Steve Ellcey wrote:

> That seems reasonable.  What arch names would you suggest for the ILP32
> builds?  I would probably go with aarch64_ilp32 and aarch32_be_ilp32
> unless there was a reason to use something else.

I'd probably use variant names rather than changing the architecture name 
in this case.
Steve Ellcey - Dec. 13, 2016, 12:16 a.m.
On Mon, 2016-12-12 at 23:57 +0000, Joseph Myers wrote:
> On Mon, 12 Dec 2016, Steve Ellcey wrote:
> 
> > 
> > That seems reasonable.  What arch names would you suggest for the
> > ILP32
> > builds?  I would probably go with aarch64_ilp32 and
> > aarch32_be_ilp32
> > unless there was a reason to use something else.
> I'd probably use variant names rather than changing the architecture name 
> in this case.

OK, I think I see how to implement that (based on examples like armeb
and m68k).  But how do you specify a variant to build on the command
line?  I.e. if I wanted to build just the coldfire variant of m68k,
what would my build-many-glibcs.py call look like to build that one
target/variant.

'build-many-glibcs.py compilers m68k-linux-gnu' would presumably just
build the default variant and not coldfire.

Steve Ellcey
sellcey@caviumnetworks.com
Joseph Myers - Dec. 13, 2016, 5:29 p.m.
On Mon, 12 Dec 2016, Steve Ellcey wrote:

> > I'd probably use variant names rather than changing the architecture name 
> > in this case.
> 
> OK, I think I see how to implement that (based on examples like armeb
> and m68k).  But how do you specify a variant to build on the command
> line?  I.e. if I wanted to build just the coldfire variant of m68k,
> what would my build-many-glibcs.py call look like to build that one
> target/variant.
> 
> 'build-many-glibcs.py compilers m68k-linux-gnu' would presumably just
> build the default variant and not coldfire.

You'd use e.g. m68k-linux-gnu-coldfire as the name on the command line.

Patch

diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index eb9b8cc..e083432 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -126,9 +126,15 @@  class Context(object):
         no_isolate = ('-fno-isolate-erroneous-paths-dereference'
                       ' -fno-isolate-erroneous-paths-attribute')
         self.add_config(arch='aarch64',
-                        os_name='linux-gnu')
+                        os_name='linux-gnu',
+                        gcc_cfg=['--with-multilib-list=lp64,ilp32'],
+                        glibcs=[{},
+                                {'variant': 'ilp32', 'ccopts': '-mabi=ilp32'}])
         self.add_config(arch='aarch64_be',
-                        os_name='linux-gnu')
+                        os_name='linux-gnu',
+                        gcc_cfg=['--with-multilib-list=lp64,ilp32'],
+                        glibcs=[{},
+                                {'variant': 'ilp32', 'ccopts': '-mabi=ilp32'}])
         self.add_config(arch='alpha',
                         os_name='linux-gnu')
         self.add_config(arch='arm',