We shouldn't need to poke these holes in seccomp now we're building the
sanitizers correctly.
Bug: http://b/229989971
Test: cuttlefish still boots with nothing untoward in the log
Change-Id: I2f9a050a86e670f000f44ad266ffdf404f3a1d1a
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
The libtest_empty.so was built by the "libtest_empty" build rule, and
the other files are copies of that with small edits made by the toybox
hexedit tool. I worked out what to edit in each case from a combination
of "what does the name imply?" and "what does a diff of the xxd output
of the corresponding two arm64 files show?".
I failed to produce a working (by which I mean "failing") local-tls
file despite my best efforts. I'm not sure what exactly it was about the
gold-generated files we didn't like, because the commentary implies that
this would be problematic:
39: 0000000000000004 4 TLS LOCAL DEFAULT 12 tls_var_2
But it loads without complaint.
Test: ran locally
Change-Id: I3b9b2b4db1f8827243541cf13380c6ceb840f123
We'll want to come back to this once either Zcmp's push/pop instructions
or V's vector loads/stores are available. But for now, we have no >64b
stores.
But at least this builds.
Test: treehugger
Change-Id: I9503e890cacb198f4ba987bfc92f6eff21c290b0
I can't find this documented anywhere, other than people observing that
RISC-V appears to behave in this way. See the LLVM commit making a
similar change to similar code, for example: https://reviews.llvm.org/D87579.
Unsatisfying, but it works, and I suspect we're all too far down this
copy & paste hole to get back out now. See also psabi bug
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/18 for
more discussion.
Change-Id: I9e9d60bf859715895370861b2024deeb1d330577
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
It's hard to find the start of the previous instruction for riscv64
(given the C extension), and discussion with the ART folks cast doubt
on the comment's claim that we do this correctly for arm32 anyway.
So, rather than add complexity for riscv64, let's simplify this routine
for everyone. I suspect we could probably get away with just `--ip` for
all architectures, but since it's trivial to at least maintain plausible
alignment, I've stuck with the correct "at least" byte counts instead.
(See the discussion on
https://lists.riscv.org/g/sig-android/topic/detecting_16_bit_vs_32_bit/94813787
for more about riscv64 specifically.)
Test: treehugger
Change-Id: Ie43451d329470b3ece8779d11eb705d24d01c3d7
We don't need this (any more than arm64 does), because riscv64 is too
new to have had a too-small sigset_t, but it's useful for source code
compatibility with code that needs to build on arm32/x86 too.
Test: treehugger
Change-Id: Ied5f64d9094bc7d31c059f82f9e4ffe9b8ca4061
These have been aliases for strtoll() and strtoull() since L, by
accident. We've never exposed them in the headers, and they're unused by
any apps. Let's fix the inconsistency between libc.so and its headers by
removing the aliases.
Bug: https://github.com/android/ndk/issues/1803
Test: treehugger
Change-Id: I87de7831c04b3e450a44e9f0386cacb73793e393
Elliott Hughes
Jooyung Han
Florian Mayer
Treehugger Robot
Martin Stjernholm
Ulya Trafimovich
Edward Liaw
zijunzhao