This mode instructs the linker to search for libraries in hwasan
subdirectories of all library search paths. This is set up to contain a
hwasan-enabled copy of libc, which is needed for HWASan programs to
operate. There are two ways this mode can be enabled:
* for native binaries, by using the linker_hwasan64 symlink as its
interpreter
* for apps: by setting the LD_HWASAN environment variable in wrap.sh
Bug: 276930343
Change-Id: I0f4117a50091616f26947fbe37a28ee573b97ad0
We want to give back a useful callee-saved general purpose
register (x18) that was only "chosen" because it was what llvm
allowed for historical reasons. gp is a better choice because it's
effectively unused otherwise anyway.
Unfortunately, that means we need extra space in jmp_buf (which I've
reserved in an earlier change, e7b3b8b467),
so let's rearrange the entries in jmp_buf to match their order in the
register file.
Bug: https://github.com/google/android-riscv64/issues/72
Bug: http://b/277909695
Test: treehugger
Change-Id: Ia629409a894c1a83d2052885702bbdd895c758e1
Bazel doesn't like it when modules produce files with the same name
as the module itself, and gives warnings.
Rename either the module or file in this case so that the file has
an extension and the module doesn't.
Bug: 198619163
Test: m nothing
Change-Id: Ic4592b06f575496ffd54ac75cb4d682118b29d93
If we switch from x18 to gp for shadow call stack, we're going to need
another slot in jmp_buf. We'll need this even for hardware shadow call
stacks too.
While I'm here, and because this is likely my last chance, let's just
round this up to 32 for safety. musl and glibc only have the minimum
needed (which I think means they'll need an ABI break to support SCS
unless they just use a callee-saved general purpose register), but since
we can't do ABI breaks after we ship, let's play it safe.
Bug: https://github.com/google/android-riscv64/issues/72
Test: treehugger
Change-Id: I60661fb7a308c900bfd08c9361f51919b798c005
The recent header nullability additions and the corresponding source
cleanup made me notice that we're missing a couple of actions that most
of the other implementations have. They've also been added to the _next_
revision of POSIX, unchanged except for the removal of the `_np` suffix.
They're trivial to implement, the testing is quite simple too, and
if they're going to be in POSIX soon, having them accessible in older
versions of Android via __RENAME() seems useful. (No-one else has shipped
the POSIX names yet.)
Bug: http://b/152414297
Test: treehugger
Change-Id: I0d2a1e47fbd2e826cff9c45038928aa1b6fcce59
Now <utmpx.h> isn't any more useful on Android than <utmp.h> is, but it
is POSIX, and -- importantly -- we can implement it with just a header
file, so code can use it on every existing API level.
macOS does indeed only have the <utmpx.h> functions (although it does
still have the <utmp.h> header!), so potentially portable code might
want <utmpx.h> on Android. (glibc/musl both have both headers.)
Bug: https://github.com/landley/toybox/pull/213
Test: treehugger
Change-Id: Iaa88167708182009a63e2e1a15f11186b251ed02
All the other architectures are already polluting the namespace with
`struct ucontext`, so make riscv64 match for source compatibility with
other Android code. (Code _should_ be using the POSIX `ucontext_t`, but
ART in particular had a lot of `struct ucontext`, and although I'll
clean that up separately, if there's some in our tree, there's probably
a lot more out there in the wild.)
Test: treehugger
Change-Id: Id0e4e97e660d7d60e792cd2462ddb9788d4772d7
We're going to dereference a null pointer if you pass one instead of a
pointer to a path, but at the moment (because of implementation sharing
between the different file actions) we won't do it until the last
minute, in the child itself. Let's crash as soon as you make the mistake
instead, to make debugging a lot easier.
Test: treehugger
Change-Id: I987d2700ba05b9867a936ebe770224259376633f
We don't really need <linux/compiler.h> and <linux/compiler_types.h>. We
already have a mechanism to remove unused macros, so let's do that. We
don't currently have a way to remove unused #includes, so we still need
<linux/compiler.h> and <linux/compiler_types.h> files (but I've clarified
the comments in them).
I've kept the empty definitions of `__user` and `__force` for source
compatibility. (We had one security test at least that was assuming
a kernel struct definition will "just work".)
Bug: http://b/262917450
Test: treehugger
Change-Id: Iacbbbc1aeef9a4fac52dabd7811ab875cc267d4f
