forked from CTSRD-CHERI/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 10
Cherry-pick changes from CTSRD main up to ca58fdbf75fca3a6a066655f4bc5802ef5b9cd07 #265
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
resistor
commented
Nov 3, 2025
- [ELF][RISCV] Support .got.plt with lazy binding for CHERI-RISC-V
- [SROA] Fix potential NULL dereference in downstream CHERI diff
- [ELF][RISCV] Fix a straggling captable comment
- [ELF] Delete dead code used for __cap_relocs in input object files
- [ELF] Don't emit capreloc for non-preemptible undef weak symbols
- Revert "cheri_init_globals.h: Explicitly set NULL capabilities"
- Use upstream method to get global addrespace (NFC)
- [CHERI] Use ABI to deduce purecap instead of default addrspace
- [NFC][ELF][Mips] Remove redundant load of in.mipsCheriCapTable
- [NFCI][ELF] Move undef weak capability code to align more with integer case
- [CHERI][ELF] Add missing REQUIRES to tests
- [test][ELF] Really fix REQUIRES:
- [CHERI] Fix a crash during codegen of __builtin_offsetof.
This is currently behind an opt-in -z cheri-riscv-jump-slot flag as it requires support in CheriBSD, but in future will become the default and only supported mode.
Depending on the iteration order we can end up attempting to dereference S.getUse() after it has been killed. The test case added does not always crash since the order of iteration over the Module does not appear to be deterministic when loaded from textual IR. However, this bug resulted in a deterministic crash when compiling X86IselLowering.cpp as part of a two-stage build with -O3.
This should have been cleaned up when CheriCapRelocsSection::addSection had its implementation (and caller) removed. Fixes: ed4dee7 ("[ELF][CHERI] GC old __cap_relocs input section code")
Currently we rely on cheri_init_globals or equivalent treating a base of 0 as NULL. Historically when caprelocs encoded the absolute base this was relatively ok, if inefficient, but with caprelocs being implicitly relative this is ambiguous, as it could instead be a relocation referring to the start of the object, which we can no longer express. We could paper over that by checking the length is 0 too (breaking only if wanting to refer to a 0-byte region at the start of the object), but it's still inefficient and unnecessary. It also failed to account for the addend, always giving NULL, not NULL + addend. Since we have a true static link time constant, we should just write out the bits for a NULL-derived capability, just as the assembler does for .chericap const. This is also important downstream for Morello, and will be important here too, as when PCC bounds are correctly set in the relocations the base could legitimately be zero for a non-preemptible symbol that isn't itself zero. Morello therefore does not treat a base of 0 as special, and so is more broken for non-preemptible undef weak symbols, deriving real (if representable) capabilities, with an address that isn't even 0 in the case of dynamically-linked binaries.
LLD now writes the NULL-derived capability instead of emitting a capreloc. This code was a bit broken for relative caprelocs, where this is an offset relative to the load base, not the absolute address, and so 0 could legitimately be a valid object. It also failed to add the offset, and doesn't work when PCC bounds are correctly set by LLD as function capabilities can legitimately have their base be the start of the object even when the function is at a non-zero offset (and it is for this reason that Morello disables this case downstream, though handled this case in LLD just as CHERI-MIPS and CHERI-RISC-V used to, so ended up trying to derive an actual capability, with a non-zero address if a PIE or DSO). This reverts commit 18506d3.
This code is in MipsCheriCapTableSection::assignIndices so this is already the .captable.
…r case Burying it in addCapabilityRelocation isn't quite right, since we don't actually want a dynamic relocation, which the name would suggest (like addRelativeReloc). This will also help for Morello LLD, which has its own addMorelloCapabilityRelocation that would otherwise need to duplicate (a subset of) the code in question.
This is a sadly a combined test for both MIPS and RISC-V. Fixes: 57fa413 ("[CHERI][ELF] Add missing REQUIRES to tests")
Occurs only when getting an offset of an item of an array member when the index cannot be constant evaluated and the type is __intcap. We need to extract the addr part of the cap before it is used as an index.
170dea8 to
4c7f066
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.