From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95854 invoked by alias); 13 Apr 2018 19:09:34 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 95845 invoked by uid 89); 13 Apr 2018 19:09:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:4.87, guy, flip, wanting X-HELO: mail.pbcl.net Message-ID: <1523646550.1959.9.camel@pbcl.net> Subject: Re: [PATCH 4/4] arm: Enable ARM mode for armv6 strlen From: Phil Blundell To: Adhemerval Zanella Cc: GNU C Library Date: Fri, 13 Apr 2018 19:09:00 -0000 In-Reply-To: References: <1523481378-16290-1-git-send-email-adhemerval.zanella@linaro.org> <1523481378-16290-4-git-send-email-adhemerval.zanella@linaro.org> <1523484770.1959.2.camel@pbcl.net> <798b9990-52ad-f6af-2aa6-fe5973e5ec94@linaro.org> <1523547184.18801.129.camel@pbcl.net> <1523561319.1959.3.camel@pbcl.net> <99d8482b-851a-fd1c-f829-f219e24d79a8@linaro.org> <1523565096.1959.5.camel@pbcl.net> <6e920ff4-b1eb-22ef-cab5-2e24f0050de5@linaro.org> <1523613389.18801.144.camel@pbcl.net> <1523623484.18801.154.camel@pbcl.net> <1523632056.18801.173.camel@pbcl.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-04/txt/msg00240.txt.bz2 On Fri, 2018-04-13 at 13:42 -0300, Adhemerval Zanella wrote: > My understanding is glibc try support kernel with missing > functionalities but either using fallback implementations (either > subpar with underlying issues as for old pipe2), emulation (as for > copy_file_range which tries to emulate the kernel behaviour), or by > just warning userland the kernel do not provide the underlying > support (for instance set_robust_list). It's true that glibc has tried (with varying levels of success) to provide compatibility implementations so that new APIs can be used on older kernels which lack some or other functionality. But this doesn't extend to working around arbitrarily broken kernel configurations. The cost of enabling CONFIG_ARM_THUMB in your kernel if you're building for ARMv7 anyway is so close to zero as to be completely negligible. There is simply no rational reason to not have it included. It would be interesting to ask the guy who filed that bugzilla ticket whether he has turned it off deliberately, and if so why. I suspect he probably just didn't realise it was needed, rather than actively wanting it off. > I really think just saying 'go fix your kernel' is not the correct > answer, even more when the configuration used is supported upstream > (it not an experimental or out-of-tree one).  There are any number of other ways in which you can break your system by configuring your kernel wrongly. The fact that the kernel config system lets you turn a given option on or off doesn't mean you can just flip switches at random and expect things to work. That said, in the particular case of CONFIG_ARM_THUMB, I think the kernel people should simply force this on when CONFIG_CPU_V7 is selected. > Also for specific case, my wild guess is using ARM code path should > not shown in much difference and will prevent such possible issues. In this particular case you're right, the ARM implementation is probably not going to perform very much worse, and now that you've fixed at least the obvious bugs I think it will probably work fine.   My concern is about the precedent it sets for the future. Right now, it clearly is not true that building glibc for ARMv7 with -marm will use only A32 instructions. Further, as far as I can tell it has never been true, so there cannot be any existing users who are depending on this behaviour. If we fix this bug in the way that you are proposing, we would be making an implicit promise that any future ARMv7-optimised assembly code is also sensitive to being compiled under -marm and will avoid Thumb2 instructions in that situation. So, all in all it seems we have a choice between: - we just tell this one guy "sorry, you have to enable CONFIG_ARM_THUMB in your kernel for glibc to work on ARMv7", he enables the option, it doesn't cost him anything, and everyone moves on; or - we fix glibc to avoid Thumb2 instructions in these assembly files, which means we now have an extra variant that we have to maintain and test, we need to remember to add the same checks to any future assembly code that might be added for v7 in the future, and we essentially can't ever stop doing that for fear that users might have become dependent on it I would prefer to do the former. p.