Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using sanitizer runtimes on RISC-V #564

Open
wants to merge 9 commits into
base: dev
Choose a base branch
from

Conversation

arichardson
Copy link
Member

Currently purecap and non-purecap runtime libs use the same library names and are installed to the same directory.
To work around this problem suffix the purecap ones with "c".

This also includes various fixes to allow building sanitizer_common for purecap again.

@arichardson arichardson marked this pull request as draft September 9, 2021 13:20
@arichardson
Copy link
Member Author

Will update after the next upstream merge.

@jrtc27
Copy link
Member

jrtc27 commented Sep 9, 2021

I figured that made most sense for this one

We currently attempt to link libclang_rt-<lib>-riscv{32,64}.a for both
purecap and non-purecap. Since there is no per-ABI subdirectory for the
compiler-rt libraries, we should be using a different basename for the
purecap runtime libs.
We have to use a different architecture suffix for purecap since not all
sanitizers are supported. We already have one for MIPS but the previous
logic to select it based on the target triple no longer works. This change
should be more future proof and sets the RISC-V architecture suffixes to
riscv{32,64}c.
This has regressed since the last merge.
We have to avoid calling renameat2 and clone on FreeBSD.
Additionally, the mcontext structure has different members.

Reviewed By: jrtc27, luismarques

Differential Revision: https://reviews.llvm.org/D103886

(cherry picked from commit b475ce3)
Currently without save.S and restore.S as those need
CTSRD-CHERI#533
Since both the plain RISC-V and purecap RISC-V compiler-rt libraries will
be installed to the same directory we have to use a different name for
the purecap ones. This patch uses a "c" suffix for the purecap ones.
@arichardson arichardson marked this pull request as ready for review September 30, 2021 15:29
@arichardson
Copy link
Member Author

rebased after merge.

@@ -167,7 +167,7 @@ namespace __sanitizer {
#if !SANITIZER_S390
uptr internal_mmap(void *addr, usize length, int prot, int flags, int fd,
u64 offset) {
#ifdef __CHERI_PURE_CAPABILITY__
#if SANITIZER_FREEBSD && defined(__CHERI_PURE_CAPABILITY__)
return (uptr)mmap(addr, length, prot, flags, fd, offset);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with internal_syscall? It returns uptr.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason that didn't work, I really can't remember why. Will need to try again.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it predates making length a usize, so the varargs nature of syscall(2) broke it?

@@ -1854,7 +1854,11 @@ SignalContext::WriteFlag SignalContext::GetWriteFlag() const {
uint32_t op_code;

# if SANITIZER_FREEBSD
# ifdef __CHERI_PURE_CAPABILITY__
exception_source = (uint32_t *)ucontext->uc_mcontext.mc_cheriframe.cf_pcc;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grr split register files

@@ -645,10 +644,15 @@ set(riscv32_SOURCES
riscv/mulsi3.S
${riscv_SOURCES}
)
set(riscv32c_SOURCES ${riscv64_SOURCES})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy-paste error, though the lists happen to be the same

@@ -606,7 +606,6 @@ set(mips64_SOURCES ${GENERIC_TF_SOURCES}
set(mips64el_SOURCES ${GENERIC_TF_SOURCES}
${mips_SOURCES})
set(mips64c128_SOURCES ${GENERIC_TF_SOURCES} ${mips_SOURCES})
set(mips64c256_SOURCES ${GENERIC_TF_SOURCES} ${mips_SOURCES})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You won't be missed...

set(riscv64_SOURCES
riscv/muldi3.S
${riscv_SOURCES}
)
set(riscv64c_SOURCES ${riscv64_SOURCES})
# save.S and restore.S need https://github.com/CTSRD-CHERI/llvm-project/pull/533
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can drop this now

@@ -1934,9 +1934,13 @@ SignalContext::WriteFlag SignalContext::GetWriteFlag() const {
return (instr >> 21) & 1 ? WRITE: READ;
#elif defined(__riscv)
#if SANITIZER_FREEBSD
unsigned long pc = ucontext->uc_mcontext.mc_gpregs.gp_sepc;
#ifdef __CHERI_PURE_CAPABILITY__
uptr pc = ucontext->uc_mcontext.mc_capregs.cp_sepcc;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sigh yes we currently do this for purecap...

@@ -2167,12 +2171,18 @@ static void GetPcSpBp(void *context, uptr *pc, uptr *sp, uptr *bp) {
# endif
*bp = ucontext->uc_mcontext.gregs[11];
*sp = ucontext->uc_mcontext.gregs[15];
#elif defined(__riscv)
ucontext_t *ucontext = (ucontext_t*)context;
# elif defined(__riscv)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the upstream formatting to reduce diffs?

if (Triple.isMIPS() && Triple.getEnvironment() == llvm::Triple::CheriPurecap) {
assert(Triple.getSubArch() != llvm::Triple::NoSubArch && "purecap triple should have subarch");
return Triple.getArchName();
if (Triple.isMIPS() && TC.isCheriPurecap()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay more CheriPurecap environment removal, last I looked at it it was a bit awkward to remove from several places but maybe I should revisit that

@jrtc27
Copy link
Member

jrtc27 commented Oct 24, 2021

Are there any implications for cheribuild here?

@arichardson
Copy link
Member Author

Are there any implications for cheribuild here?

I believe some currently broken stuff might start working (building both compiler-rt-riscv64 and compiler-rt-riscv64-purecap), otherwise I don't think so.

@jrtc27
Copy link
Member

jrtc27 commented Oct 24, 2021

Are there any implications for cheribuild here?

I believe some currently broken stuff might start working (building both compiler-rt-riscv64 and compiler-rt-riscv64-purecap), otherwise I don't think so.

I believe the targets have knowledge about the names of the libraries though so might break or do weird things.

@@ -395,14 +395,14 @@ class DeadlockDetector {
int unique_tid;
};

uptr current_epoch_;
usize current_epoch_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I changed all the indices, etc. in this file to also be usize. The only thing in this file that holds actual pointers is the data_ array.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants