Correct outdated object size limit

The comment here about 48 bit addresses being enough was written in 2016
but was made incorrect in 2019 by 5-level paging, and then persisted for
another 5 years before being noticed and corrected.
This commit is contained in:
Jubilee Young 2024-07-09 18:09:56 -07:00
parent 506f22b466
commit 42dbf29b48

View File

@ -337,23 +337,21 @@ pub fn parse_from_llvm_datalayout_string<'a>(
Ok(dl)
}
/// Returns exclusive upper bound on object size.
/// Returns **exclusive** upper bound on object size.
///
/// The theoretical maximum object size is defined as the maximum positive `isize` value.
/// This ensures that the `offset` semantics remain well-defined by allowing it to correctly
/// index every address within an object along with one byte past the end, along with allowing
/// `isize` to store the difference between any two pointers into an object.
///
/// The upper bound on 64-bit currently needs to be lower because LLVM uses a 64-bit integer
/// to represent object size in bits. It would need to be 1 << 61 to account for this, but is
/// currently conservatively bounded to 1 << 47 as that is enough to cover the current usable
/// address space on 64-bit ARMv8 and x86_64.
/// LLVM uses a 64-bit integer to represent object size in bits, but we care only for bytes,
/// so we adopt such a more-constrained address space due to its technical limitations.
#[inline]
pub fn obj_size_bound(&self) -> u64 {
match self.pointer_size.bits() {
16 => 1 << 15,
32 => 1 << 31,
64 => 1 << 47,
64 => 1 << 61,
bits => panic!("obj_size_bound: unknown pointer bit size {bits}"),
}
}