| Message ID | 201612122202.uBCM2JuU006047@sellcey-lt.caveonetworks.com |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 100538 invoked by alias); 12 Dec 2016 22:02:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 100439 invoked by uid 89); 12 Dec 2016 22:02:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=lp64, ellcey, Ellcey, 1269 X-HELO: camailhost.cavium.com Date: Mon, 12 Dec 2016 14:02:19 -0800 From: Steve Ellcey <sellcey@cavium.com> Message-Id: <201612122202.uBCM2JuU006047@sellcey-lt.caveonetworks.com> To: libc-alpha@sourceware.org Subject: build-many-glibcs.py question (updating for multilibs on aarch64) Reply-To: sellcey@cavium.com |
Commit Message
Steve Ellcey
Dec. 12, 2016, 10:02 p.m. UTC
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
Comments
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.
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
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.
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
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.
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
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.
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',