This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]