This patch adds support to load BTI-enabled objects.
According to the ABI, BTI is recorded in the .note.gnu.property section.
The new parser evaluates the property section, if exists.
It searches for .note section with NT_GNU_PROPERTY_TYPE_0.
Once found it tries to find GNU_PROPERTY_AARCH64_FEATURE_1_AND.
The results are cached.
The main change in linker is when protection of loaded ranges gets
applied. When BTI is requested and the platform also supports it
the prot flags have to be amended with PROT_BTI for executable ranges.
Failing to add PROT_BTI flag would disable BTI protection.
Moreover, adding the new PROT flag for shared objects without BTI
compatibility would break applications.
Kernel does not add PROT_BTI to a loaded ELF which has interpreter.
Linker handles this case too.
Test: 1. Flame boots
2. Tested on FVP with BTI enabled
Change-Id: Iafdf223b74c6e75d9f17ca90500e6fe42c4c1218
It was originally based on fdlibm, but it's been through two different
projects since then, and `git blame` shows basically nothing remaining
from those days. Seems worth leaving something to explain the unusual
copyright header though!
Test: treehugger
Change-Id: I8e7252a755704b866e7f36c8e97adc021fa3cdad
Except they are the same on arm32/arm64, so we hadn't really noticed. x86
and x86-64 are quite different though, presumably by historical accident.
Fix the definitions and add some static asserts.
Bug: https://github.com/android/ndk/issues/1347
Test: treehugger
Change-Id: Ic27b172066cf3443749463b9b73c912d204f9516
We don't list most of bionic on dac since it would be overwhelming for
the current layout, but this file in particular seems useful,
especially __ANDROID_API__. Unfortunately, c2devsite doesn't include
macro documentation. Until then, it's still useful to include the
functions defined in this header.
I've also elaborated a bit in the __ANDROID_API__ documentation, since
the existing phrasing led to confusion over whether it was closer to
minSdkVersion or compileSdkVersion. In practice these are identical
for the NDK, but if we switch to weakly-linked APIs via the
availability attribute that would change.
Test: built docs, looked at them
Bug: None
Change-Id: I5cf78a6143b5c15790c369bdf888611e4c1189db
(Based on proposal at https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
This includes API to:
- locate static and dynamic TLS
- register thread-exit and dynamic TLS creation/destruction callbacks
Change-Id: Icd9d29a5b2f47495395645e19d3b2c96826f19c8
Now we're being marked down for our poor coverage, we may as well remove
more broken cruft. Despite the amount of effort that seems to have gone
into pututline(), it wasn't working with the other utmp.h functions (in
particular, utmpname()), and wasn't declared in the header file!
Test: treehugger
Change-Id: I1a583984189c751168c11c01431433f96f8c548b
This was initially just to try on "pty" and "tty" for size, while
discussing with other projects to try to align on vocabulary, but -- in
the implemention and tests at least -- but these work out so well that
I'm tempted to go with them anyway if we can't come to a concensus. We
can always come back and change them again later.
What I really like is that you pass the pty to functions like ptsname()
and grantpt() with a 'p' in the name, and the tty to functions like
ttyname() and tcsetattr() with just 't's.
The use of "parent" and "child" in forkpty() seems helpful too.
Also fix the documentation of forkpty(), which wasn't quite right.
Test: treehugger
Change-Id: Ic010c4b669f6528591c653e3701f4e41e0d0df9e
1) "fix the system properties design" is written for the old protocol,
so we've already changed the design. There are no other further
planned changes.
2) "don't drag in all the macros, just the types." is not likely to
happen or be particularly impactful.
3) "Find a location suitable for these functions ..." is refering to
legacy code. More likely that this code will be removed before we
find a serious reason to fix this TODO.
4) "(73062966) We still don't have a good way ..." is stale; we fixed
this bug and added the appropriate mechanism.
Test: n/a
Change-Id: I23991692cdeb81ad00844a6a1680900ff384208b
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.6
Add a new method for removing structures. This is to deal with the kernel
headers changing some definitions of timeval to __kernel_old_timeval
and itimerval to __kernel_old_itimerval. Remove the __kernel_old_XX
strutures and change the other structures to the previous definitions.
This only works so long as these structures stay the same, if they
diverge, then a different strategy will need to be implemented.
Test: Booted cuttlefish/walleye.
Test: Ran bionic-unit-tests on cuttlefish/walleye.
Change-Id: I0a61f4fa6e4155c602e0414d9b38c2e1637829af
This was a side-effect of something else I was doing. May as well check
this in now though.
Test: treehugger
Change-Id: Ibe8a3640d309c1980fa6e8ef003d4f255384c9e7
POSIX added these GNU extensions for issue 8.
I've made these always inline without the usual "until API level X"
proviso because they're single instructions that the compiler can inline
and there's really no point providing these if they add function call
overhead --- everyone should just use __builtin_ffs() and friends
instead in that case.
Bug: https://austingroupbugs.net/view.php?id=617
Test: treehugger
Change-Id: I33fc4b8648ea25917329e81c1b4c60eb9a66d667
LLVM now knows how to fold __strlen_chk, so we can make this function a
one-liner.
Also fix strlcat to not double-return while I'm in the area.
Bug: 148189733
Test: TreeHugger
Change-Id: I71ee308defbefe96f3fe6e357a2127309d2f0942
I had hoped that this would then let us remove more of the "introduced
in" annotations, but it looks like that's not really going to happen
until the NDK's minimum supported API is 21.
Also remove a .c file that wasn't referenced anywhere.
Test: treehugger
Change-Id: I8b4a61c082293f8445195a4fa5ee30595d70444e
We've optimized the ctype functions to the point where they're pretty
much all down to one instruction. This change takes the obvious next
step of just inlining them.
On Android these function have only ever been for ASCII. You need the
<wctype.h> functions for non-ASCII.
libc++ currently has its own inlines for the _l variants, so if we want
to just inline them in bionic directly, we'll need to coordinate that.
Bug: http://b/144165498
Test: treehugger plus benchmarks
Change-Id: I4cc8aa96f7994ae710a562cfc9d4f220ab7babd6
Over the last year, LLVM apparently learned how to optimize many
FORTIFY'ed functions. I went through the list of functions it optimizes,
and simplified their implementations here.
This is more than a code health thing; __bos_trivially_ge expands to a
branch that's not eliminated until after inlining, so it can actually
cause some functions (like one of std::string's ctors) to become
uninlineable.
Bug: 148189733
Test: hand-checked the IR we get for each of the changed functions. Many
get optimized to their non-_chk variant when appropriate. Others
will get optimized to non-_chk versions when bos == -1. Bug repro
also now shows all 'inline's.
Change-Id: Ic360818ad9daaeda3958e1282af41087f85122a3
If we remove the mips uapi headers, versioner fails because it assumes
they're available. We'll need a new versioner prebuilt beforre we can
remove the libc/versioner-dependencies/mips* symlinks.
Test: treehugger
Change-Id: Ife6df0cb57938f806a31ec334d648df9694c3d17
Many of our header files are very sensitive to the order in which
their #includes appear...
Bug: N/A
Test: N/A
Change-Id: I2c21cac5e9bd49b7e80620d14971af8fefa17e91
On Android, fcntl is always implemented by fcntl64(2). This means that
an LP32 binary can `fcntl(F_SETLK, struct flock)` (because fcntl64(2)
passes through to the 32-bit fcntl(2) to handle F_SETLK), and it can
also `fcntl(F_SETLK64, struct flock64)`. What it can't do before this
patch is set _FILE_OFFSET_BITS=64 and then `fcntl(F_SETLK, struct
flock)` where that `struct flock` is actually implicitly `struct
flock64`.
Move the kernel uapi structs out of the way, define them ourselves based
on __LP64__ and _FILE_OFFSET_BITS, and fix up the relevant F_ constants.
(Also add a .clang-format to turn off clang-format in libc/include/.)
Bug: N/A
Test: treehugger (and strace!)
Change-Id: Iccd6c83d9133e1efcf93a7b49a6ae0f1bbd3d58b
Until now we've only supported RELR with our own OS-private-use
constants. Add support for the official numbers (while maintaining
support for the historical numbers).
Add tests to ensure we continue to support both indefinitely.
We can't yet flip the build system over to using the official constants
because the old GNU binutils objcopy we still use in most cases (for the
mini-debug section) only supports the historical constants.
Bug: http://b/147452927
Test: treehugger
Change-Id: If214fce7fade4316115947e90b78ab40864b61f2
