Skip to content

Pointer encoding limits address space to 24bits for ILP32 #94

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

Open
peterschrammel opened this issue May 20, 2016 · 0 comments
Open

Pointer encoding limits address space to 24bits for ILP32 #94

peterschrammel opened this issue May 20, 2016 · 0 comments

Comments

@peterschrammel
Copy link
Member

The following fails when checking with --ilp32 (for nbytes >=2^24)

uint32_t nondet_uint32_t();

void mk_char_array() {
uint32_t nbytes = nondet_uint32_t();
char memory[nbytes];
char *start = &memory[0];
char *end = &memory[nbytes];
uint32_t diff = end - start;
__CPROVER_assert(diff == nbytes, "Check size match");
}

It's rare to allocate arrays of that size in software, and few people use ILP32, however, the restriction is an unnecessary artefact of the encoding that CBMC uses (upper 8 bits for object reference, remaining bits for offset within the object)...
The problem doesn't occur with LP64 (64-8 > 48).

Issue raised by Nathan Chong, ARM.

tautschnig added a commit to tautschnig/cbmc that referenced this issue Dec 8, 2017
Instead of encoding pointers with the same bit width a pointer on a given
platform has, just widen the bit-blasted encoding to include both the previous
object/offset encoding as well as an (integer) address. The encoding is thus
also trivially be extended to handle larger numbers of objects and offsets of
the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make in-code
layout of pointer encoding more natural (it's now object, offset,
integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
tautschnig added a commit to tautschnig/cbmc that referenced this issue Apr 15, 2018
Instead of encoding pointers with the same bit width a pointer on a given
platform has, just widen the bit-blasted encoding to include both the previous
object/offset encoding as well as an (integer) address. The encoding is thus
also trivially be extended to handle larger numbers of objects and offsets of
the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make in-code
layout of pointer encoding more natural (it's now object, offset,
integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
tautschnig added a commit to tautschnig/cbmc that referenced this issue Apr 18, 2018
Instead of encoding pointers with the same bit width a pointer on a given
platform has, just widen the bit-blasted encoding to include both the previous
object/offset encoding as well as an (integer) address. The encoding is thus
also trivially extended to handle larger numbers of objects and offsets of the
same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make in-code
layout of pointer encoding more natural (it's now object, offset,
integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
smowton pushed a commit to smowton/cbmc that referenced this issue May 9, 2018
…ap-const_iterator

Nathan/feature/virtual map const iterator
tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 12, 2021
Instead of encoding pointers with the same bit width a pointer on a
given platform has, just widen the bit-blasted encoding to include both
the previous object/offset encoding as well as an (integer) address. The
encoding is thus also trivially extended to handle larger numbers of
objects and offsets of the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make
in-code layout of pointer encoding more natural (it's now object,
offset, integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 12, 2021
Instead of encoding pointers with the same bit width a pointer on a
given platform has, just widen the bit-blasted encoding to include both
the previous object/offset encoding as well as an (integer) address. The
encoding is thus also trivially extended to handle larger numbers of
objects and offsets of the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make
in-code layout of pointer encoding more natural (it's now object,
offset, integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 12, 2021
Instead of encoding pointers with the same bit width a pointer on a
given platform has, just widen the bit-blasted encoding to include both
the previous object/offset encoding as well as an (integer) address. The
encoding is thus also trivially extended to handle larger numbers of
objects and offsets of the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make
in-code layout of pointer encoding more natural (it's now object,
offset, integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
tautschnig added a commit to tautschnig/cbmc that referenced this issue Jun 12, 2021
Instead of encoding pointers with the same bit width a pointer on a
given platform has, just widen the bit-blasted encoding to include both
the previous object/offset encoding as well as an (integer) address. The
encoding is thus also trivially extended to handle larger numbers of
objects and offsets of the same width as the address.

Furthermore clean up the code to encapsulate encoding properly, and make
in-code layout of pointer encoding more natural (it's now object,
offset, integer-address).

Fixes: diffblue#436
Fixes: diffblue#311
Fixes: diffblue#94
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants