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

Add clang-tidy checker to look for imprecise sub-object bounds. #705

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

qwattash
Copy link
Contributor

The clang-tidy checker should not do anything particularly complicated, it assumes that the structure is allocated at a properly aligned base and uses the offset of the fields to see whether the resulting capability would be exactly representable. The diagnostic is a bit verbose because I'm using it to get information out to plot, it would be nice to have some more structured output but I'm not sure whether there is a preferred way of doing that.

This also bumps the cheri-compressed-cap subtree.

@jrtc27
Copy link
Member

jrtc27 commented Jun 22, 2023

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

@qwattash
Copy link
Contributor Author

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

Uhm I thought I did it through git subtree but I may have done a quick hack just to check if it worked. Will edit it to make it the right way.

@arichardson
Copy link
Member

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

Uhm I thought I did it through git subtree but I may have done a quick hack just to check if it worked. Will edit it to make it the right way.

The problem is that when you click rebase and merge the hashes change so it's no longer correct unless you push directly.

This check inspects structure fields and emits a warning if the field offset or
size may be rounded when creating a capability for the sub-object.
This assumes that the parent structure is suitably aligned to a representable
boundary for its size.
@qwattash
Copy link
Contributor Author

qwattash commented Jun 22, 2023

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

Uhm I thought I did it through git subtree but I may have done a quick hack just to check if it worked. Will edit it to make it the right way.

The problem is that when you click rebase and merge the hashes change so it's no longer correct unless you push directly.

As an aside I thought git subtree was used but it appears that the git subrepo tool instead was used. I'm not familiar with it but attempting to use git subrepo pull <path> -b master fails with "Fatal: needed a single revision" and overwrites my last commit message with some text.

EDIT:
I think somehow the git subrepo information have gotten desynchronized with the cheri-compressed-cap repo

@arichardson
Copy link
Member

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

Uhm I thought I did it through git subtree but I may have done a quick hack just to check if it worked. Will edit it to make it the right way.

The problem is that when you click rebase and merge the hashes change so it's no longer correct unless you push directly.

As an aside I thought git subtree was used but it appears that the git subrepo tool instead was used. I'm not familiar with it but attempting to use git subrepo pull <path> -b master fails with "Fatal: needed a single revision" and overwrites my last commit message with some text.

EDIT: I think somehow the git subrepo information have gotten desynchronized with the cheri-compressed-cap repo

I can take care of updating the compressed cap repo but I'd like to merge CTSRD-CHERI/cheri-compressed-cap#18 first since that includes an API change.

@qwattash
Copy link
Contributor Author

qwattash commented Jun 22, 2023

Updating the subtree needs to be done specially as otherwise GitHub will rebase and screw up the hashes

Uhm I thought I did it through git subtree but I may have done a quick hack just to check if it worked. Will edit it to make it the right way.

The problem is that when you click rebase and merge the hashes change so it's no longer correct unless you push directly.

As an aside I thought git subtree was used but it appears that the git subrepo tool instead was used. I'm not familiar with it but attempting to use git subrepo pull <path> -b master fails with "Fatal: needed a single revision" and overwrites my last commit message with some text.
EDIT: I think somehow the git subrepo information have gotten desynchronized with the cheri-compressed-cap repo

I can take care of updating the compressed cap repo but I'd like to merge CTSRD-CHERI/cheri-compressed-cap#18 first since that includes an API change.

No worries, this is not urgent anyway. This just seems some tooling issue on my side. Let me know when it is safe to do, if you want me to do the cheri-compressed-cap bump :)

@qwattash qwattash force-pushed the representable-subobject-diagniostic branch from 7b27afe to 3b783f5 Compare June 23, 2023 13:19
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.

3 participants