Mainly just factoring out the code, but there are two functional
changes here too:
1. The inline assembler was missing `volatile`, making the hwcap
check ineffective (because the compiler would sometimes move the
MIDR_EL1 read above the hwcap check).
2. The previous code accepted variants 0x0 to 0x5 while the comment
said 0x1 to 0x5. The comment was correct.
I resisted the temptation to actually have a table to search on the assumption that it'll be a while before we need such a thing.
Bug: https://issuetracker.google.com/330105715
Change-Id: I9fdc1e70e49b26ef32794b55ca5e5fd37f1163f9
Submitted on behalf of a third-party: Linaro Limited
License rights, if any, to the submission are granted solely by the
copyright owner of such submission under its applicable intellectual
property.
Copyright (c) 2012, Linaro Limited
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the Linaro nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Origin Project URL: https://android.googlesource.com/platform/bionic/
Commit ID: 7e4fa56099
Third Party code includes additions/modifications from Qualcomm Innovation Center, Inc.
Test: All
Change-Id: I479a572a325e27262d27aa37c516618e4322e9bb
Submitted on behalf of a third-party: Arm Limited
License rights, if any, to the submission are granted solely by the
copyright owner of such submission under its applicable intellectual
property.
Copyright (c) 2012-2022, Arm Limited.
SPDX-License-Identifier: MIT OR Apache-2.0 WITH LLVM-exception
Origin Project URL: https://github.com/ARM-software/optimized-routines
Tag: v24.01
Third Party code includes additions/modifications from Qualcomm Innovation Center, Inc.
Test: All
Change-Id: I0c97398a435e3f8ddf8ad38bc6bd71cc0d78aea5
Not useful right now, but Qualcomm has an Oryon memset they'd like to
use, and there's no reason to treat memrchr as a weird special case.
Bug: https://issuetracker.google.com/330105715
Test: treehugger
Change-Id: Id879479bf4f45433debcb3fe08cfa96bb1eb3b93
No actual effect on the code, but misleading and wrong. (The previous
change only fixed the argument types; I didn't notice that some of the
return types were wrong too.)
Test: treehugger
Change-Id: I1ee5c48e2652fd8cbf8178d5659e57f79e61898e
This patch doesn't *enable* the SVE optimized routines, but it does let
us see if switching them to ifuncs will cause any app compat issues, so
that we can more easily use the optimized routines in future.
Test: treehugger
Change-Id: Ic5fe570bd21687da397b48127bf688f7ec68dd0c
The MTE-compatible routines are now faster than the incompatible ones,
so they merged them upstream.
I've left the ifunc boilerplate on the assumption that I'll be back
later to enable the new SVE variants.
Test: treehugger
Change-Id: Ic894bfb350b9aa70e307bca1c4978624b3e5f4fd
Outsource this to them, and choose the best of the two options available
based on the hardware we're running on.
Test: treehugger
Change-Id: I2fa7555c971b64a6decca132210e901ffa248efa
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
ARM has released the remaining MTE string routines, so let's start
using them. The strnlen implementation is now compatible with MTE,
so it no longer needs to be an ifunc.
Bug: 135772972
Change-Id: I9de7fb44447aa1b878f4ad3f62cb0129857b43ad
This includes optimized strrchr and strchrnul routines, and an MTE-compatible
strlen routine.
Bug: 135772972
Change-Id: I48499f757cdc6d3e77e5649123d45b17dfa3c6b0
As it turns out, our "generic" arm64 implementations of certain string.h
functions are not actually generic, since they will eagerly read memory
possibly outside of the bounds of an MTE granule, which may lead to a segfault
on MTE-enabled hardware. Therefore, move the implementations into a "default"
directory and use ifuncs to select between them and a new set of "mte"
implementations, conditional on whether the hardware and kernel support MTE.
The MTE implementations are currently naive implementations written in C
but will later be replaced with a set of optimized assembly implementations.
Bug: 135772972
Change-Id: Ife37c4e0e6fd60ff20a34594cc09c541af4d1dd7
