Message ID | 87d0j0lap3.fsf@oldenburg2.str.redhat.com |
---|---|
State | Committed |
Commit | 72edea80c1bb402f41d8bca58c835abf46dadd48 |
Headers |
Received: (qmail 96874 invoked by alias); 26 Jun 2019 13:48:22 -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 96569 invoked by uid 89); 26 Jun 2019 13:48:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=linuxgnu, linux-gnu, 00000000 X-HELO: mx1.redhat.com From: Florian Weimer <fweimer@redhat.com> To: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Phil Blundell <pb@pbcl.net>, libc-alpha@sourceware.org Subject: Re: [PATCH] Remove ioperm etc. support for arm References: <87o93lo3y9.fsf@oldenburg2.str.redhat.com> <20190529135135.rt3c5fhhser7fik6@hetzner.pbcl.net> <875zptqrwx.fsf@oldenburg2.str.redhat.com> <20190529141820.5nny64ugrvqyzqgd@hetzner.pbcl.net> <87r28hpb0l.fsf_-_@oldenburg2.str.redhat.com> <20190529184028.GC24195@darkstar.musicnaut.iki.fi> <87ef4hp08c.fsf@oldenburg2.str.redhat.com> <20190529201227.GD24195@darkstar.musicnaut.iki.fi> <87imttnewj.fsf@oldenburg2.str.redhat.com> <20190606215312.GB11598@darkstar.musicnaut.iki.fi> Date: Wed, 26 Jun 2019 15:48:08 +0200 In-Reply-To: <20190606215312.GB11598@darkstar.musicnaut.iki.fi> (Aaro Koskinen's message of "Fri, 7 Jun 2019 00:53:12 +0300") Message-ID: <87d0j0lap3.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain |
Commit Message
Florian Weimer
June 26, 2019, 1:48 p.m. UTC
* Aaro Koskinen: > Hi, > > On Wed, May 29, 2019 at 11:12:44PM +0200, Florian Weimer wrote: >> >> Maybe we used to test ARMv4, and GCC changed under us without us >> >> noticing? >> > >> > Don't know if they have ever changed that, but it would probably make >> > sense to add flags to build-many-glibcs.py to build for the lowest >> > supported arch level. >> >> Indeed. >> >> > ARMv4 is already deprecated in GCC, so probably it's OK to remove this >> > stuff from glibc. Personally I'm concerned about armv4t support as I'm >> > running such systems still with modern glibc. >> >> Interesting. Could you perhaps suggest changes to build-many-glibcs.py >> so that we can build an armv4t target as part of the regular runs? > > Just building with -march=armv4t should be enough for a start. This architecture doesn't have its own target triplet, right? With the patch below, I get this in csu/init-first.os: 00000000 <__libc_init_first>: 0: e12fff1e bx lr 0: R_ARM_V4BX *ABS* But after linking, get this in libc.so.6: 000175a0 <__libc_init_first>: 175a0: e12fff1e bx lr Does this mean I need to pass some other flags as well? Sorry, I'm really not familiar with Arm at all. Thanks, Florian build-many-glibcs.py: Add v4t variant for arm-linux-gnueabi 2019-06-26 Florian Weimer <fweimer@redhat.com> * scripts/build-many-glibcs.py (Context.add_all_configs): Add v4t variant for arm-linux-gnueabi.
Comments
On Wed, Jun 26, 2019 at 03:48:08PM +0200, Florian Weimer wrote: > * Aaro Koskinen: > > Just building with -march=armv4t should be enough for a start. > > This architecture doesn't have its own target triplet, right? Right. You can configure with "armv4t-unknown-linuxgnueabi" if you like but I don't think the glibc configury does anything different for "armv4t" than for plain "arm". > With the patch below, I get this in csu/init-first.os: > > 00000000 <__libc_init_first>: > 0: e12fff1e bx lr > 0: R_ARM_V4BX *ABS* > > But after linking, get this in libc.so.6: > > 000175a0 <__libc_init_first>: > 175a0: e12fff1e bx lr > > Does this mean I need to pass some other flags as well? No, that looks about right. ARMv4T does have "bx rN" so it is OK for that instruction to be generated. You might be thinking of ARMv4, which doesn't have bx at all and needs the linker to patch them (gcc passes --fix-v4bx from its specs when building for ARMv4) or the "blx" instruction which is only in ARMv5T and upwards. p.
* Phil Blundell: > On Wed, Jun 26, 2019 at 03:48:08PM +0200, Florian Weimer wrote: >> * Aaro Koskinen: >> > Just building with -march=armv4t should be enough for a start. >> >> This architecture doesn't have its own target triplet, right? > > Right. You can configure with "armv4t-unknown-linuxgnueabi" if > you like but I don't think the glibc configury does anything > different for "armv4t" than for plain "arm". > >> With the patch below, I get this in csu/init-first.os: >> >> 00000000 <__libc_init_first>: >> 0: e12fff1e bx lr >> 0: R_ARM_V4BX *ABS* >> >> But after linking, get this in libc.so.6: >> >> 000175a0 <__libc_init_first>: >> 175a0: e12fff1e bx lr >> >> Does this mean I need to pass some other flags as well? > > No, that looks about right. ARMv4T does have "bx rN" so it > is OK for that instruction to be generated. You might be > thinking of ARMv4, which doesn't have bx at all and needs > the linker to patch them (gcc passes --fix-v4bx from its > specs when building for ARMv4) or the "blx" instruction > which is only in ARMv5T and upwards. Okay, so the patch is essentially complete? I don't know if the code generation and relocation differences make this a viable additional architecture build-only testing. Do you have an opinion regarding this matter? Thanks, Florian
On Wed, Jun 26, 2019 at 05:23:32PM +0200, Florian Weimer wrote: > Okay, so the patch is essentially complete? I think so. I will give it a try later and see if I can confirm that it's doing the right thing, but assuming that the -march= setting is indeed ending up on the compiler command line then I think the answer is that the patch is correct. > I don't know if the code generation and relocation differences make this > a viable additional architecture build-only testing. Do you have an > opinion regarding this matter? Yes, I think it's a useful test. The assembler knows what instructions are allowed in each architecture, so this build test is sufficient to confirm (for example) that no blx instructions have leaked into the generic ARM assembly sources without being suitably protected. p.
* Phil Blundell: > On Wed, Jun 26, 2019 at 05:23:32PM +0200, Florian Weimer wrote: >> Okay, so the patch is essentially complete? > > I think so. I will give it a try later and see if I can confirm > that it's doing the right thing, but assuming that the -march= > setting is indeed ending up on the compiler command line then I > think the answer is that the patch is correct. Thanks, that would be useful information to have. If it all works out, I will push my patch. Florian
On Wed, Jun 26, 2019 at 05:56:15PM +0200, Florian Weimer wrote: > * Phil Blundell: > > I think so. I will give it a try later and see if I can confirm > > that it's doing the right thing, but assuming that the -march= > > setting is indeed ending up on the compiler command line then I > > think the answer is that the patch is correct. > > Thanks, that would be useful information to have. If it all works out, > I will push my patch. I (finally!) inspected the output from build-many-glibcs.py with your patch and it looks correct for ARMv4T. So I think you can go ahead and push that. Sorry it took me so long. Thanks Phil
* Phil Blundell: > On Wed, Jun 26, 2019 at 05:56:15PM +0200, Florian Weimer wrote: >> * Phil Blundell: >> > I think so. I will give it a try later and see if I can confirm >> > that it's doing the right thing, but assuming that the -march= >> > setting is indeed ending up on the compiler command line then I >> > think the answer is that the patch is correct. >> >> Thanks, that would be useful information to have. If it all works out, >> I will push my patch. > > I (finally!) inspected the output from build-many-glibcs.py with your > patch and it looks correct for ARMv4T. So I think you can go ahead > and push that. Sorry it took me so long. Thanks, I've pushed my patch. Florian
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py index c5821df25e..dacd116f8e 100755 --- a/scripts/build-many-glibcs.py +++ b/scripts/build-many-glibcs.py @@ -158,7 +158,9 @@ class Context(object): self.add_config(arch='alpha', os_name='linux-gnu') self.add_config(arch='arm', - os_name='linux-gnueabi') + os_name='linux-gnueabi', + extra_glibcs=[{'variant': 'v4t', + 'ccopts': '-march=armv4t'}]) self.add_config(arch='armeb', os_name='linux-gnueabi') self.add_config(arch='armeb',