* changes:
Expose unwinder APIs in NDK stubs for R and up.
Use abi::__cxa_demangle declared in cxxabi.h
__cxa_atexit_test: declare __cxa_atexit and __cxa_finalize
Trying to find a leak this year, it was very annoying that our traces
were mostly filled with "junk" frames from the JNI implementation,
making it quite a struggle to see what the actual calling code was...
Bug: http://b/236197847
Test: treehugger
Change-Id: I69e7d9b6432e1872e238168ebf3dc36feb7de7df
We still have local differences, but this minimizes (and documents) them.
Bug: http://b/167569813
Test: treehugger
Change-Id: Ib90e6ccc5ec1224e7ee89224a51b87fc48c9931f
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
These APIs are exposed in the on-device libc.so's .dynsym table from R
and up (e.g. _Unwind_xxx@@LIBC_R), but they were only available in the
APEX and LLNDK stubs. Expose the symbols from the NDK stubs too so that
the LLVM toolchain build can build a libc++.so that imports the
unwinder from libc.so. (The platform/APEX libc++.so will become a
toolchain prebuilt.)
Eventually this change will also allows apps to use the unwinder from
libc.so rather than linking libunwind.a statically.
Bug: http://b/175635923
Test: treehugger
Change-Id: I7ba9cef9a4727b49dd717e25a0321bf2889694de
After updating libc++, they're no longer declared in cxxabi.h, so the
test must declare them locally.
8bd0dc5bfe
Temporarily use a return type of "int" to avoid a Clang error about
conflicting return types.
Bug: http://b/175635923
Test: treehugger
Change-Id: I16ba3dc8cc84cc18ee7fbfe9d2e3fa0cd4eefeae
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
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
