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

MPI_Aint needs to be wide enough to hold a pointer, not just an address #709

Open
jeffhammond opened this issue May 3, 2023 · 0 comments
Assignees
Labels
chap-datatypes Datatypes Chapter Committee mpi-5 For inclusion in the MPI 5.0 standard

Comments

@jeffhammond
Copy link
Member

jeffhammond commented May 3, 2023

Problem

I understand we designed MPI_GET_ADDRESS and related concepts around segmented addressing, where an address is bigger than a pointer. Thus, we created a way to turn pointers into addresses, and have a thing called an address integer.

While segmented addressing is no longer relevant anywhere I can see, except the C standard, we now see platforms where pointers are bigger than addresses. For example, https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf. In this platform, which has silicon implementations, pointers are larger than addresses (often 128b versus 64b).

More importantly, on the CHERI platform, addresses cannot be converted to dereferenceable pointers without the use of an existing valid pointer [1]. As such, if one were to use MPI_GET_ADDRESS as prescribed and create a datatype based absolute addressing and pass MPI_BOTTOM as the buffer, the MPI implementation cannot use the buffer associated with that datatype without manually defeating the memory safety mechanisms built into the platform.

[1] "vaddr_t This is a new integer type introduced by CHERI C and should be used to hold virtual addresses. vaddr_t should not be directly cast to a pointer type for dereference; instead, it must be combined with an existing valid capability to the address space to generate a dereferenceable pointer.Typically, this is done using the cheri_address_set(c, x) function." (From the link)

Proposal

We must explicitly say that MPI_Aint is large enough to hold a pointer. On the CHERI platform, intptr_t is the only integer kind that can be used to store a pointer. Unfortunately, there are apparently two platforms where intptr_t is not supported (due to intmax_t ABI compatibility problems) so we cannot strictly assume it, although we can say that MPI_Aint must be equivalent to its definition in C.

Changes to the Text

TODO

Impact on Implementations

This is not an issue on most platforms, but is solved by ensuring that MPI_Aint is equivalent to intptr_t.

Impact on Users

This is necessary to ensure MPI will work on platforms with fat pointers.

References and Pull Requests

@jeffhammond jeffhammond self-assigned this May 3, 2023
@jeffhammond jeffhammond changed the title MPI_Aint needs to be wide enough to hold a pointers, not just an address MPI_Aint needs to be wide enough to hold a pointer, not just an address May 3, 2023
@wesbland wesbland added mpi-5 For inclusion in the MPI 5.0 standard chap-datatypes Datatypes Chapter Committee labels Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chap-datatypes Datatypes Chapter Committee mpi-5 For inclusion in the MPI 5.0 standard
Projects
Status: To Do
Development

No branches or pull requests

2 participants