From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20396 invoked by alias); 16 Apr 2018 14:16:31 -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 20385 invoked by uid 89); 16 Apr 2018 14:16:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=guy, wanting, repeating, negligible X-HELO: foss.arm.com Subject: Re: [PATCH 4/4] arm: Enable ARM mode for armv6 strlen To: Phil Blundell , Adhemerval Zanella Cc: GNU C Library 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> <1523646550.1959.9.camel@pbcl.net> From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Autocrypt: addr=Richard.Earnshaw@arm.com; prefer-encrypt=mutual; keydata= xsDiBEjjjXcRBADwG6UA7HMYfwxecIFq6nmNzzRj1bAwt0CSPp56Kbd6kKZofc5WA9RHYRq8 X00NL0IXhByAJOC3rCU0uJArA/PO5aBh9xO8LGy82FpYQXc1OP7LL+4DLUS/ExPkHh7fBlzP 2sTzv1FFqwAVMFTPbTzyePmhjEnvXF5PNp5MTL3mlwCgiFB4ZYEG/5PCgUmC4HDF4ImYSCcE ANUPwtmP3Rad6DDOJTOijNQJVsPb2xatLQ79TzWK47Cv6OnsgxiyB5VbOHPiuHvvmBNBN3EB /3rweNAAsPeMYMnh2L1uI+hQD0Y5tVYdbQohfvZEQGxyrloWRCqjg8nANRLxCmTpKoeMNMS/ Tl3ayp9gQQO2j4G3CUNTohYKQ1ckA/9YQSn41fO5gFbP6erWv2Rdq7hrIwhiEbJb7VcNck+g B7xFZcinu98Y+T2ClJXY/hHKOQdwNWG/3JVw5JWPQ6u3rfRYl6rlwK9Pav8ICfrzNdmiekcE xwNnN7C01PE7krOhyuvbuPxyRYe/TUOX8un/+B9ffSktIEYTfXkdb9Aohs0rUmljaGFyZCBF YXJuc2hhdyA8UmljaGFyZC5FYXJuc2hhd0Bhcm0uY29tPsJgBBMRAgAgBQJI4413AhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AACgkQ13ksTIWEXSSmpgCfZ+QBeZJH3TvWXuZ20E63MdJr uMAAnj77Olwjw4wl16griDwLDCatLZN1zsBNBEjjjXgQBAD+yyTRclefTl19lP9W1AEB9E32 VS4Xa1qY9hkYdMNIaXL3VHhqCyyNLIzXigP1gciwjwRdluA+klRODhANWlFzJAdvlb+Ai/61 Lty1+OCoi3TvHas6n5DNRwxxrUsZ7ZgcM+KxQ4BJcXlpDmH+S8K/0JHHmq2M1h48G6itStS/ vwADBQQAj0UeskGLotqFc+MOgaFZNyWizz7hFAfiOhFV14jmJ4J27eRwvfP9q5VkoUzqtWd6 b//e622/5o58/3cuE8ZqanPAZMRtPHDURjlXXk+R30QMGrrCr+rdv+CaNJ/7LeeCACiUW+XQ t9DKlcY32DIxjmEOY9XHYzbX8kFIDNMbvYDCSQQYEQIACQUCSOONeAIbDAAKCRDXeSxMhYRd JOKiAJwJZ2MKa0ehMrf6/nG6PJRCvjkDHACeM1axixZdvw1PRp2rp41EIKxGSq8= Message-ID: <0724c8f4-31b8-a6f8-d2d7-834a40a2e6d3@arm.com> Date: Mon, 16 Apr 2018 14:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1523646550.1959.9.camel@pbcl.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-04/txt/msg00263.txt.bz2 On 13/04/18 20:09, Phil Blundell wrote: > 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 > +1 for all of the above :-) > - 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. It takes a lot of work to tune the routines written in assembler across a range of processors. Needlessly repeating that for perverse kernel configurations is just make work. R.