Skip to content

Make pointer encoding sound wrt integer address translation (and lift object limits) #1086

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

Closed
wants to merge 5 commits into from

Conversation

tautschnig
Copy link
Collaborator

@tautschnig tautschnig commented Jul 4, 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: #436
Fixes: #311
Fixes: #94

@tautschnig
Copy link
Collaborator Author

tautschnig commented Aug 11, 2017

As far as I'm aware this is now complete (and working) for the SAT back end. The work left to be done is getting #982 merged, adjusting the SMT back ends to do the same. [edit: done]

We would then no longer have any limit on the number of objects or the particular addresses that pointers take.

@tautschnig tautschnig changed the title Change pointer encoding to include integer addresses Make pointer encoding sound wrt integer address translation (and lift object limits) Aug 11, 2017
@tautschnig tautschnig changed the title Make pointer encoding sound wrt integer address translation (and lift object limits) [depends: #982] Make pointer encoding sound wrt integer address translation (and lift object limits) Aug 11, 2017
@tautschnig tautschnig force-pushed the memory-region branch 2 times, most recently from 6fdf7d2 to 11bd809 Compare August 14, 2017 13:15
@tautschnig tautschnig removed their assignment Aug 14, 2017
@tautschnig tautschnig self-assigned this Aug 20, 2017
@tautschnig tautschnig changed the base branch from master to develop August 22, 2017 12:21
@tautschnig tautschnig changed the title [depends: #982] Make pointer encoding sound wrt integer address translation (and lift object limits) Make pointer encoding sound wrt integer address translation (and lift object limits) Sep 1, 2017
@martin-cs
Copy link
Collaborator

Another "how alive / urgent is this one" type question?

@tautschnig
Copy link
Collaborator Author

It has been among the top elements on my stack for the last couple of weeks; realistically it will stay there until Christmas...

@tautschnig
Copy link
Collaborator Author

This should be ready for review now. I am aware that possible feedback includes "please refactor into multiple, smaller PRs." All feedback appreciated (including that one). A known point of concern, voiced by @kroening earlier: the pointer flattening is not amenable to incremental use. Ideas to fix that are most welcome!

Copy link
Contributor

@thk123 thk123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the changes in src/analyses only - some suggestions for making it more obvious what is going on but in principle seems correct. They to be honest seem like they could be pulled into their own PR and merged quickly.

expr.id()==ID_minus)
if(expr.id()!=ID_plus &&
expr.id()!=ID_minus)
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: since condition is multiple lines can you wrap the return in braces

// The overflow checks are binary!
// We break these up.

for(unsigned i=1; i<expr.operands().size(); i++)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I needed a pen and paper to fully get what was going on here. I wonder if a comment with an example explaining the calls to pointer_overflow_check would help?

// an operand with 4 children, a, b, c, d we:
// first check (a, b)
// then c with a temporary expression with two children: (a, b)
// then d with a temporary expression with three children: (a, b, c)

else
{
tmp=expr;
tmp.operands().resize(i);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to make it explicit here that you are chopping off the last nodes for now to do an intermediate check

@thk123
Copy link
Contributor

thk123 commented Dec 21, 2017

I've created a TG PR to verify this doesn't break anything, but TBH looks like it won't be a problem: diffblue/test-gen#1322

@thk123
Copy link
Contributor

thk123 commented Dec 21, 2017

TG PR fails, but for what looks like rebase reasons, can I ask for this PR to be rebased on to current head of develop?

@smowton
Copy link
Contributor

smowton commented Jan 5, 2018

Guessing this needs @kroening's opinion?

@tautschnig
Copy link
Collaborator Author

This mainly needs work on my end to enable incremental use.

@tautschnig
Copy link
Collaborator Author

I have now created #2059, #2060, #2061, #2062, #2063, #2064, #2065, #2066 (and might create at least one more) to place all the preparatory work in separate pull requests that can reasonably be reviewed.

The tests exercise the way the back-end encodes pointers. Upcoming
encoding changes will ensure that these can soundly be handled.
Rather than handling the object/offset bit width in multiple places,
make boolbv_widtht the only place to provide this information.
This is in preparation of the flattened bit width of pointers not
necessarily matching the width claimed by the front-end.
This keeps configurable aspects out of bv_pointerst.
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
@codecov
Copy link

codecov bot commented Feb 12, 2021

Codecov Report

Merging #1086 (bb9c198) into develop (23c11e8) will decrease coverage by 36.82%.
The diff coverage is 15.32%.

Impacted file tree graph

@@             Coverage Diff              @@
##           develop    #1086       +/-   ##
============================================
- Coverage    69.08%   32.25%   -36.83%     
============================================
  Files         1242      984      -258     
  Lines       100842    83944    -16898     
============================================
- Hits         69667    27080    -42587     
- Misses       31175    56864    +25689     
Flag Coverage Δ
regression ?
unit 32.25% <15.32%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/solvers/flattening/boolbv_byte_extract.cpp 0.00% <0.00%> (-72.59%) ⬇️
src/solvers/flattening/boolbv_byte_update.cpp 0.00% <0.00%> (-100.00%) ⬇️
src/solvers/flattening/boolbv_width.h 100.00% <ø> (ø)
src/solvers/flattening/bv_pointers.h 11.11% <0.00%> (-88.89%) ⬇️
src/solvers/flattening/pointer_logic.h 0.00% <ø> (-50.00%) ⬇️
src/solvers/smt2/smt2_conv.cpp 0.00% <0.00%> (-31.31%) ⬇️
src/solvers/flattening/bv_pointers.cpp 16.37% <14.83%> (-66.69%) ⬇️
src/solvers/flattening/boolbv_width.cpp 39.25% <100.00%> (-33.20%) ⬇️
src/solvers/flattening/pointer_logic.cpp 8.95% <100.00%> (-72.87%) ⬇️
src/cpp/cpp_id.h 0.00% <0.00%> (-100.00%) ⬇️
... and 963 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23c11e8...bb9c198. Read the comment docs.

@TGWDB
Copy link
Contributor

TGWDB commented Aug 5, 2021

@tautschnig This looks interesting but very out of date now. I notice it was close to the top of your stack a few years ago, does that still hold, or has this fallen too far down to keep open? Generally we'd like to close old PRs that are not going to happen.

@TGWDB
Copy link
Contributor

TGWDB commented Sep 13, 2021

Closing due to age and not being actively worked on. Please reopen if you believe this is erroneous and new work towards merging this PR has progressed.

@TGWDB TGWDB closed this Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants