[PATCH 4/4] arm: Enable ARM mode for armv6 strlen

[Adhemerval Zanella]

On 13/04/2018 12:07, Phil Blundell wrote:
> On Fri, 2018-04-13 at 11:40 -0300, Adhemerval Zanella wrote:
>> I am not against reverting it, but it does not help the scenario of 
>> BZ#23031.  We need to define whether environments which thumb is
>> expected to be supported but it is not enabled by compiler flags
>> (-marm) and act accordingly by avoid building glibc in such cases.
> 
> My position on that remains that the scenario of BZ#23031 is simply
> invalid and the user's expectations are just misplaced.  The fact that
> we've had sysdeps/arm/armv6t2/memchr.S using Thumb code since December
> 2011 and in those six years it's only generated one bug report seems to
> support the belief that there is not a large population of users trying
> to do this sort of thing.

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).

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).  Also for specific case, my wild guess 
is using ARM code path should not shown in much difference and will 
prevent such possible issues.

> 
> I don't think -marm has ever been intended to mean "don't allow any
> Thumb instructions in my program".  The whole -marm/-mthumb thing dates
> from ARMv4T/Thumb-1 days when interworking couldn't be taken for
> granted and Thumb code often ran significantly slower than the
> equivalent ARM code.  Under those circumstances it was necessary for
> the user to be able to choose what instruction encoding the compiler
> was going to generate.
> 
> But here we are, two decades later, and the landscape is a bit
> different.  It's not entirely clear that -marm/-mthumb are very useful
> options in an ARMv7 world because the user shouldn't need to care.  In
> an ideal world the compiler would be able to predict for any given
> function whether T32 or A32 encoding would give the best results
> (either speed or space according to the selected optimisation settings)
>  and proceed accordingly.  Unfortunately in practice I don't think
> we're quite there yet and for critical code there's still an element of
> "try building it both ways round and see which one runs quickest" which
> means the compiler flags probably are still necessary.  Users might
> even legitimately wish to try that experiment with glibc, so forbidding
> them to compile it under -marm would not obviously be the right thing
> to do.
> 
> p.
>