Merge further changes from CTSRD main up to 7385a57cdd2b819aa1b9e608cf479e18e7eb70b6 #267
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
These will need to add PLT entries for non-preemptible symbols, but not for IFUNCs, which was the real thing we can't support. Teach addPltEntry to be able to create cap relocs for non-preemptible symbols and push the IFUNC check down into CheriCapRelocsSection where it belongs.
This will allow the entire block to be guarded by !AArch64 for Morello.
We don't currently permit this bool to be true, but Morello LLD does (and it's implicitly true there for dynamically-linked binaries) and shouldn't run this block.
Our use of cap relocs here is equivalent to a relative relocation, so teach addRelativeReloc how to handle capabilities and align more with upstream in addGotEntry. Passing R_CHERI_CAPABILITY rather than R_ABS in the preemptible case shouldn't matter as I don't think it's read, but is now more consistent. The intent is that R_ABS is an absolute address and R_CHERI_CAPABILITY is an absolute capability, and for relative ELF relocs (whether using a CBuildCap-like or a Morello fragment format) we can add static internal relocations to write out the capability/fragment bits in the same place as is done for the addend for Elf_Rel relocations, rather than littering extra relocation additions throughout.
Passing R_CHERI_CAPABILITY to addReloc here is a hack; it should really be R_ADDEND since expr here is for the addend not the whole relocation, but we pass R_CHERI_CAPABILITY to mean "R_ADDEND but it's for a capability" so we can do this check. Instead, push it to the sole caller that actually passes R_CHERI_CAPABILITY today (the one that is used for capability relocations in input files, which is the case we need to overwrite the addend for on MIPS).
This is now entirely equivalent to R_ADDEND, so switch to that, mirroring how normal dynamic absolute relocations are added.
These are the actual target relocations and not the RelExpr.
We want capabilities to follow R_ABS as closely as possible so rename it to match what it really is and move it into the generic range.
Keeping this message is going to be annoying for upcoming refactorings and CHERI MIPS is dead, so sacrifice it.
These call sites were using addCapabilityRelocation with the expectation that it would only ever create a relative relocation (i.e. a capreloc). Now that there's a dedicated function for that, call it directly rather than it looking like it could end up with a relocation against a symbol.
…iRelocs The point of this is to control whether we are using real ELF relocations to encode what are logically relative relocations, rather than caprelocs. Whichever is the case, we still need some form of relative relocation. Make that clearer, as the current name makes some of the code look very strange (in particular, the calls to the new addRelativeCapabilityRelocation).
Currently we use symbolicRel as addendRelType for symbolic capability relocations, but this is an annoying special case to have. Instead, allow passing the original type through and treat it as a way to write the addend (or, in future, a word of the raw capability bits, or in the case of Morello downstream, the fragment).
…elocation The special trampoline handling, at the end of the day, is just ensuring that we don't use caprelocs for function pointers that need a trampoline at run time, and caprelocs are just how we encode relative relocations. Moving it here hides that implementation detail. The one downside of this is that we lose "Using trampoline for function pointer against ..." messages for symbols that were already preemptible, but that's not very interesting as nothing was actually being done differently there. As a result the message is tweaked to reflect what it (now) represents.
…otEntry Rather than use addCapabilityRelocation, expand out the various conditions more like is done in addGotEntry.
All current calls leave shard as false, but this will not be true in future. We don't currently have the ability to shard caprelocs so we pretend it's sharded by taking relocMutex.
Currently R_ABS_CAP has special handling before the point where this is called in processAux, but that will soon change.
With the right helpers hooked we need almost no special support any more in processAux.
This was only templated downstream as it called addCapabilityRelocation, which used to be a template.
Treating addConstant as an alias for the equivalent function will let us more easily extend both.
Since isStaticLinkTimeConstant will return true for these we don't need the early return, we can just let the static relocation be added just like for GOT indices. Note also, now that CHERI-RISC-V is using the normal GOT, we don't need to take relocMutex, as parallel execution is disabled for MIPS (its GOT implementation also isn't parallel-safe). Also use addReloc like is now done upstream for the MIPS GOT.
This is now treated as an implementation detail for how a static R_ABS_CAP is internally implemented. This infrastructure can also be reused in future for relative relocations.
Left over from a previous version of the commit. Fixes: 950bd69 ("[NFCI][ELF][CHERI] Teach addSymbolReloc to handle capabilities and use")
…s. (CTSRD-CHERI#780) This is in preparation for standard CHERI encodings. Use the unprefixed instruction mnemonics in compiler-rt and libunwind, to support both xcheri and RVY.
(cherry picked from commit 529efc4)
This is error-prone in case new bit patterns are allocated, as will shortly be done. We can't fix that problem for existing versions, but we can avoid it going forwards.
…ions We don't know what future bit patterns will mean, so don't even try, as that's likely to be misleading.
This requires the run time to opt in though so we don't silently leave IRELATIVE capabilities uninitialised.
Code pointers are like function pointers, but they should not be wrapped in trampolines when c18n is enabled. They are mainly used for C++ exceptions landing pads, among other things. This permissions should be OR'ed with the existing 'function' permission when used. Note that, absent a c18n implementation, which will need to have custom handling of function relocations and so cannot use this implementation, the two can be treated identically.
resistor
force-pushed
the
ctsrd-update
branch
from
2365283 to
54ebc2c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Uh oh!
There was an error while loading. Please reload this page.