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.
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
Add
CapbilityPtr
and AddSuccessAddr
andSuccessPtr
syscall variants #4174Add
CapbilityPtr
and AddSuccessAddr
andSuccessPtr
syscall variants #4174Changes from 1 commit
12abe15
c32507d
677183f
6254b9e
a5ee396
fd51098
c97deea
291c8f4
695af1b
7ec6bdd
d0fa5fc
be62a66
950deb2
236a8ac
a4e5936
9ac666b
010bf22
604460c
79b2b8d
6feb692
f800ddd
2cd33d2
bf24e72
d569776
743c8cd
144269e
cc0b53e
45f8a44
391dfc8
8f8ce44
a5e5a6d
f3feec6
a001b33
7ea663f
9560125
670a5d0
3810ca8
0709e6a
1ebf509
d23676d
38a5188
08caaa5
c6156c8
a803e1e
096536c
3c1876b
37cb959
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...although
into_compat
will reverse this again.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is OK because a
MetaPtr
is always convertible into a raw pointer by just losing any meta information. However, might be better to implement this for<T> *const T
(which can always be cast to ausize
anyway)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add that too (it might even exist as a method?), but this one gets used a lot in syscall / return argument handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah got it. Does this imply that those arguments or returns should actually be
*const T
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its happening a lot because values that are usize, or even eventually u32, are being passed in registers that can hold something as wide as
MetaPtr
(the widest type, or so I have assumed).@bradjc has suggested that maybe those should be a separate
RegisterData
type, something large enough to holdu32
/isize
/*const()
/MetaPtr
.I suppose, fairly, one could imagine a platform with pointers that are smaller than u32, in which case really RegisterData would wrap around the largest type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documenting that
CapabilityPtr
is a pointer then using it to store other things is very confusing, and I think having a separateRegisterData
[1] type would help that confusion.CapabilityPtr
is already a confusing enough type to understand, especially for contributors who are unfamiliar with CHERI.The fact that some CHERI systems use different registers for integers and capabilities however, does throw a wrench into the works. However, there are two obvious ways that come to mind for how we might choose to handle that at the ABI level:
usize
for the integer registers andCapabilityPtr
for the capability registers [2].RegisterData
for all the register values.In both cases, it makes sense to only use
CapabilityPtr
for pointer types, so I don't think it's really a blocker for having bothCapabilityPtr
andRegisterData
. Option 1 would be somewhat awkward, though, because we would only useRegisterData
for the capability registers.[1] libtock-rs just calls this
Register
[2] This ignores the possibility of non-pointer capabilities, which is another complication
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not convinced
RegisterData
is really a single type. Machines have different width registers. To say thatRegisterData
should refer to just one of them is odd to me. If we did introduce aRegisterData
here, I would expect it to wrapCapabilityPtr
(with an appropriate comment saying the type is being used because it is expected to be widest). It would certainly throw a spanner if ever a different ABI were introduced that actually used different width registers, to have aRegisterData
and thenSomeOtherRegisterData
. But I am happy to addRegisterData
if that is the consensus and makes the syscall layer easier to understand.