File size increase were found negligible from sparseness and zero
block compression in f2fs and ext4 (supported filesystems for
Android's userdata partition).
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Co-authored-by: Kalesh Singh <kaleshsingh@google.com>
If using multiarch directories with musl, the multiarch directory still
uses *-linux-gnu triples - which may or may not be intentional, while it
is somewhat consistent at least.
However, for musl armhf targets, make sure that this also picks
arm-linux-gnueabihf, rather than arm-linux-gnueabi.
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half
is used by kernel. There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is
ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36 Loader, vdso and other
libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27,
hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
D145214 was reverted because one file was missing in the latest commit.
Luckily the file was there in the previous commit, probably the author
missed uploading that file with latest commit.
Co-authored-by: Alex Fan <alex.fan.q@gmail.com>
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half is used by kernel.
There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36
Loader, vdso and other libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27, hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
Make minor changes to enable DFSAN and its tests on
loongarch64. And port Linux loongarch64 memory mappings
from msan.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D140690
This will enable layering multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
This change doesn't expose the functionality externally, it only opens
the functionality up to be potentially used by ToolChain classes.
Differential Revision: https://reviews.llvm.org/D143059
This will allow to compile binaries that use hwasan to run on a
non-HWASan system image.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D151388
ELFObjectWriter.cpp may report
```
error: Cannot represent a difference across sections
```
on some ppc64be configurations, likely related to some interaction
between the obsoleted ELFv1 and MC.
Unfortunately I cannot reproduce this locally with --target=powerpc64-linux-gnu.
Functions instrumented with -fsanitize=function have two words before
the function label: a signature and a RTTI proxy.
Instrumented call sites check the signature first to skip checks
for uninstrumented callees.
The code is generic and works for all targets supporting C++ RTTI.
Change clangDriver to allow all targets. Add tests for Armv8.5
Branch Target Identification and `-fpatchable-function-entry=`.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D148573
Enable -fsanitize=kernel-memory support in Clang.
The x86_64 ABI requires that shadow_origin_ptr_t must be returned via a
register pair, and the s390x ABI requires that it must be returned via
memory pointed to by a hidden parameter. Normally Clang takes care of
the ABI, but the sanitizers run long after it, so unfortunately they
have to duplicate the ABI logic.
Therefore add a special case for SystemZ and manually emit the
s390x-ABI-compliant calling sequences. Since it's only 2 architectures,
do not create a VarArgHelper-like abstraction layer.
The kernel functions are compiled with the "packed-stack" and
"use-soft-float" attributes. For the "packed-stack" functions, it's not
correct for copyRegSaveArea() to copy 160 bytes of shadow and origins,
since the save area is dynamically sized. Things are greatly simplified
by the fact that the vararg "use-soft-float" functions use precisely
56 bytes in order to save the argument registers to where va_arg() can
find them.
Make copyRegSaveArea() copy only 56 bytes in the "use-soft-float" case.
The "packed-stack" && !"use-soft-float" case has no practical uses at
the moment, so leave it for the future.
Add tests.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D148596
We don't support the LLVM_ENABLE_PROJECTS=libcxx build anymore (and have
not for over a year), so it should be fine to remove this workaround now.
Differential Revision: https://reviews.llvm.org/D148945
This follows v1.00 of the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conventions ]],
but notably with [[ https://github.com/loongson/LoongArch-Documentation/pull/80 | this patch ]]
applied (a proper version bump to v2.00 was not done, so it is
indistinguishable from the "original" but now incompatible v1.00
otherwise).
Only `loongarch64` is implemented in `Linux::getMultiarchTriple`
because support for LA32 and ILP32* ABIs are incomplete right now.
The Debian sysroot layout is based on Han Gao's recent porting effort,
specifically the ghcr.io/rabenda/beige:loong64-v23-preview-20230330
container image.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D142688
Enable Scudo on RISCV64 on both clang side and compiler-rt side.
Reviewers: cryptoad, eugenis, vitalybuka, luismarques, hiraditya
Reviewed By: vitalybuka, luismarques
Differential Revision: https://reviews.llvm.org/D137397
HIP runtime is the language runtime of HIP. When users need
to specify rpath, they usually need to specify rpath for
both compiler-rt and HIP runtime. It seems redundant
to have separate options. Therefore make --offload-add-rpath
an alias to -frtlib-add-rpath.
Reviewed by: Fangrui Song, Artem Belevich
Differential Revision: https://reviews.llvm.org/D145393
Lazyly initialize uncommon toolchain detector
Cuda and rocm toolchain detectors are currently run unconditionally,
while their result may not be used at all. Make their initialization
lazy so that the discovery code is not run in common cases.
Reapplied since 77910ac374656319ff114ef251fda358d4aa166a landed and
fixes the test ordering issue.
Differential Revision: https://reviews.llvm.org/D142606
Cuda and rocm toolchain detectors are currently run unconditionally,
while their result may not be used at all. Make their initialization
lazy so that the discovery code is not run in common cases.
Differential Revision: https://reviews.llvm.org/D142606
Reviewed by: vitalybuka, kito-cheng
These changes will allow to use HWASAN with RISCV64 architecture.
The majority of existing tests are passing with a few exceptions(see below).
The tests were running on QEMU, since currently there're no hardware with support
for J-extension.
For this feature to work the system must support PR_{SET,GET}_TAGGED_ADDR_CTRL
syscall. For now this is only available for a patched Linux kernel and QEMU with
enabled experimental J-extension.
Results of running HWASAN lit tests for RISC-V:
```
Unsupported : 6
Passed : 79
Expectedly Failed: 2
```
Tests are marked as expected to fail or unsupported either because of:
- android platform not being supported
- no support for legacy hwasan v1 mode
- test config explicitly uses aarch64 option
```
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/abort-message-android.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/cfi.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/lto.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/print-memory-usage-android.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/register-dump-read.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/try-catch.cpp
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/stack-oob.c
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/exported-tagged-global.c
```
Differential Revision: https://reviews.llvm.org/D131345
This patch enabled tsan for loongarch64 with 47-bit VMA layout. All
tests are passing.
Also adds assembly routines to enable setjmp/longjmp for loongarch64
on linux.
Reviewed By: dvyukov, SixWeining, #sanitizers
Differential Revision: https://reviews.llvm.org/D138489
Add an option --[no-]offload-add-rpath to control whether to
pass -rpath to linker for HIP runtime library. By default it
is off to match gcc/clang behavior for not adding -rpath
for runtime library by default.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D136854
The clang distributed with the Android NDK has defaulted to lld since r22,
so let's update the driver to match.
Differential Revision: https://reviews.llvm.org/D135421
To align with many Linux distributions which configure GCC with
--enable-default-hash-style=gnu or binutils with --with-linker-hash-style=gnu.
ld.lld does not support changed default, so passing the option in the driver is
better.
Note: there was a bug that Debian specified both --hash-style=gnu and
--hash-style=both. Actually its GCC has defaulted to --hash-style=gnu since 2007.
This commit reverts the following commits:
- 952f90b72b3546d6b6b038d410f07ce520c59b48
- e6a0800532bb409f6d1c62f3698bdd6994a877dc (D132298)
- 176db3b3ab25ff8a9b2405f50ef5a8bd9304a6d5 (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
With the initial support added, clang can compile `helloworld` C
to executable file for loongarch64. For example:
```
$ cat hello.c
int main() {
printf("Hello, world!\n");
return 0;
}
$ clang --target=loongarch64-unknown-linux-gnu --gcc-toolchain=xxx --sysroot=xxx hello.c
```
The output a.out can run within qemu or native machine. For example:
```
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0, with debug_info, not stripped
$ ./a.out
Hello, world!
```
Currently gcc toolchain and sysroot can be found here:
https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note loongarch32 is not fully tested because there is no reference
gcc toolchain yet.
Differential Revision: https://reviews.llvm.org/D130255
This patch does the following:
- Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new.
tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this.
- Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie"
command line options.
- Adds the above options to flang/Frontend/CodeGenOptions' data structure.
- Sets the relocation model in the target machine, and
- Sets module flags for the respective PIC/PIE type in LLVM IR.
I have tried my best to replicate how clang does things.
Differential Revision: https://reviews.llvm.org/D131533
Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
In, https://reviews.llvm.org/D120305, CLANG_DEFAULT_PIE_ON_LINUX was set
to `On` by default. However, neither `-fpie` nor `-fpic` are currently
supported in LLVM Flang. Hence, in this patch the behaviour controlled
with CLANG_DEFAULT_PIE_ON_LINUX is refined not to apply to Flang.
Another way to look at this is that CLANG_DEFAULT_PIE_ON_LINUX is
currently affecting both Clang and Flang. IIUC, the intention for this
CMake variable has always been to only affect Clang. This patch makes
sure that that's the case.
Without this change, you might see errors like this on X86_64:
```
/usr/bin/ld: main.o: relocation R_X86_64_32 against `.bss' can not be used when making a PIE object; recompile with -fPIC
```
I've not experienced any issues on AArch64. That's probably because on
AArch64 some object files happen to be position independent without
needing -fpie or -fpic.
Differential Revision: https://reviews.llvm.org/D128333
Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`.
If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible.
This change makes sure that the include paths start with a single slash.
Fixes#28283.
Differential Revision: https://reviews.llvm.org/D126289
Add CSKY target toolchains to support csky in linux and elf environment.
It can leverage the basic universal Linux toolchain for linux environment, and only add some compile or link parameters.
For elf environment, add a CSKYToolChain to support compile and link.
Also add some parameters into basic codebase of clang driver.
Differential Revision: https://reviews.llvm.org/D121445
--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
composing smaller options. We need to figure out alternative solution
and what is missing among these basic options.
The rule was added in 2014 to support -stdlib=libc++ and -lc++ without
specifying -L, when D.Dir is not a well-known system library directory like
/usr/lib /usr/lib64. This rule turns out to get in the way with (-m32 for
64-bit clang) or (-m64 for 32-bit clang) for Gentoo :
https://github.com/llvm/llvm-project/issues/54515
Nowadays LLVM_ENABLE_RUNTIMES is the only recommended way building libc++ and
LLVM_ENABLE_PROJECTS=libc++ is deprecated. LLVM_ENABLE_RUNTIMES builds libc++
in D.Dir+"/../lib/${triple}/". The rule is unneeded. Also reverts D108286.
Gentoo uses a modified LLVM_ENABLE_RUNTIMES that installs libc++.so in
well-known paths like /usr/lib64 and /usr/lib which are already covered by
nearby search paths.
Implication: if a downstream package needs something like -lLLVM-15git and uses
libLLVM-15git.so not in a well-known path, it needs to supply -L
D.Dir+"/../lib" explicitly (e.g. via LLVMConfig.cmake), instead of relying on
the previous default search path.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D122444
In some cases, we need to set alternative toolchain path other than the
default with system (headers, libraries, dynamic linker prefix, ld path,
etc.), e.g., to pick up newer components, but keep sysroot at the same
time (to pick up extra packages).
This change introduces a new option --overlay-platform-toolchain to set
up such alternative toolchain path.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D121992
In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,
* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.
This has been adopted by all(?) major distros.
I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).
This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.
Reviewed By: foutrelis, sylvestre.ledru, thesamesam
Differential Revision: https://reviews.llvm.org/D113372
