Once we have an llvm with https://reviews.llvm.org/D136508, we will be
able to defer to more compiler builtins, but for now let's do what we
can...
Test: llvm-objdump (plus the tests still pass!)
Change-Id: Ia5c704409ca88ab1a02342c1b5dde8525da95243
We don't support GCC any more, and clang's got better since this commit
was written. It doesn't produce _identical_ code, but it's a similar
single-instruction bit twiddle.
This also doesn't regress x86 for fabsl (that code looks the same before
and after) and there is no riscv32.
Test: llvm-objdump -d
Change-Id: I7acea6fd26f8760763f3744201ed42a99186562b
Remove copy_file_range(2), preadv2(2), and pwritev2(2), all of which are
now in SYSCALLS.TXT.
Remove semtimedop_time64(2) since it doesn't make any sense to have an
exception for just the 64-bit-time_t-on-LP32 variant of a syscall we
don't even use --- this is the least likely variant of that syscall
to need an exception!
Also clean up the unnecessary foo:foo syntax (you only need the : if you
want the generated stub to have a different name, and here the names
were all identical _and_ the whole point of this file is to list
syscalls that we're not generating stubs for, this was doubly useless),
simplify the signatures to just the types (which is all we need), and
improve some of the commentary.
Test: treehugger
Change-Id: I691b5758a2165be9bbeafdd83f0c64d7eea987e5
Treehugger didn't test 32-bit (and neither, of course, had I), so we
didn't notice until the next day that I'd only added the new check to
the 64-bit codepath. Let's just unify the two, since there's only one
line of meaningful difference.
Bug: http://b/261092827
Test: treehugger
Change-Id: I5178257a76fe24a340b3659c85ad29ed0a7b8b50
android_namespace_link_t::shared_lib_sonames_ is unorderd_set<string>.
When initializing, it's copied a few times unnecessarily.
- when add_linked_namespace is called
- when android_namespace_link_t() is called
- when push_back is called.
Now, it's moved around after the initial creation.
Bug: n/a
Test: atest --test-mapping .
Change-Id: I283954bb0c0bbf94ebd74407137f492e08fd41bd
We stopped accepting new code in this form (compiler output from
compilers we don't have compiling source we don't have [or possibly the
same source we do have --- how would be know?]) years ago, but never
went back to clean up existing instances.
This doesn't affect the string/memory routines, which are intelligible,
nor all of the libm stuff (we're keeping the intelligible subset), but
does affect all the trig functions.
The right way to do this is to either have commented hand-written
assembler (which we have always taken, and will continue to take) or to
have C/C++ source that can be built with LLVM (which will then be built
as part of the regular build). This is what we do for arm/arm64, for
example, with the C/C++ source coming from
https://github.com/ARM-software/optimized-routines and being mirrored
in external/arm-optimized-routines, and built by Android's clang at
build time.
Test: treehugger
Change-Id: Icd69ef34b8a9ea16ea2b7d5d6587c2a9143b7740
As of https://r.android.com/2304013 classloader namespaces are no
longer called "classloader-namespace". However, this whole TODO is
stale - it was supposed to be addressed in O and it only applies to
compat code for SDK < 24, so there is no use fixing it now.
Test: N/A - comment change only
Bug: 258340826
Change-Id: Id09e262191cea236224196a4a4268331d5cf84c6
This one's a bit simpler, because there is only one upstream memset()
implementation.
Test: treehugger
Change-Id: I2536d0eb72adaacfa6a0e40d2bd29fc833988c16
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
These two will stay behind when we move memcpy()/memmove()/memset() over
to arm-optimized-routines (which leaves fortify to us).
Test: treehugger
Change-Id: Ie683f71a5a141263ce3f4e8811df9eaf667584f4
Just to make it clear that there's nothing interesting going on here ---
there's just one user, and the only symbol here is __memcpy().
Test: treehugger
Change-Id: I62d72c43c4c6d30442f05c1e08a0cb1a1ec42a8a
The compiler turns our C wmemmove() into one shift instruction and a
branch, which is plenty for a function no-one uses anyway.
Why don't I just leave this alone, since we already have it? Because I'm
looking at finishing the project of "switch to arm-optimized-routines"
and getting rid of our assembler here, and Arm agrees that this isn't
worth having optimized assembler for in their optimized assembler
project, judging by its absence.
Test: treehugger
Change-Id: I985801241a8cbd7dbda51a447946affb1402effb
