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

Support opaque pointers in llvm_fresh_expanded_val #1879

Open
RyanGlScott opened this issue Jun 1, 2023 · 0 comments
Open

Support opaque pointers in llvm_fresh_expanded_val #1879

RyanGlScott opened this issue Jun 1, 2023 · 0 comments
Labels
needs design Technical design work is needed for issue to progress subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm type: enhancement Issues describing an improvement to an existing feature or capability

Comments

@RyanGlScott
Copy link
Contributor

I have recently updated SAW to work with LLVM's opaque pointers, an LLVM language change that replaces pointers with explicit pointee types (e.g., i32*) with opaque pointers that lack pointee types. In an opaque pointer setting, all pointers have the type ptr, and LLVM determines how to interpret the underlying memory based on the types of instructions that the pointers are used in. For more information, see the following links:

While most parts of SAW now fully support opaque pointers, there is one part of SAW that cannot handle them at the moment: the llvm_fresh_expanded_val command. This can be seen by running the following SAW script (using #1878):

// test.c
void f(int* x) {}
// test.saw
let f_spec = do {
    val <- llvm_fresh_expanded_val (llvm_type "ptr");
    llvm_execute_func [val];
};

m <- llvm_load_module "test.bc";
ov <- llvm_verify m "f" [] false f_spec z3;
$ ~/Software/clang+llvm-16.0.0/bin/clang -g -c -emit-llvm test.c
$ ./bin/saw test.saw



[12:02:45.670] Loading file "/home/ryanglscott/Documents/Hacking/Haskell/saw-script/test.saw"
[12:02:45.673] Stack trace:
"llvm_verify" (/home/ryanglscott/Documents/Hacking/Haskell/saw-script/test.saw:8:7-8:18)
llvm_fresh_expanded_var: PtrOpaque not supported

It's not clear to me what the right behavior should be for fresh opaque pointers. There is already a case for non-opaque pointers:

Crucible.PtrType symTy ->
case Crucible.asMemType symTy of
Right memTy -> constructFreshPointer (symTypeAlias symTy) loc memTy
Left err -> throwCrucibleSetup loc $ unlines
[ "lhs not a valid pointer type: " ++ show symTy
, "Details:"
, err
]

This case will construct a SAW allocation using the same machinery as the llvm_fresh_pointer command. This command relies on knowing what the pointer's pointee type is, however, and we don't have access to pointee types for opaque pointers.

One possibility is to just return a null pointer when making a fresh opaque pointer. This would work, but it would be noticeably different from how non-opaque pointers are treated, which could be confusing.

For now, I am going to make calling llvm_fresh_expanded_val on an opaque pointer an error. We can revisit this if someone expresses a desire for it.

@RyanGlScott RyanGlScott added type: enhancement Issues describing an improvement to an existing feature or capability subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm needs design Technical design work is needed for issue to progress labels Jun 1, 2023
RyanGlScott added a commit that referenced this issue Jun 1, 2023
This patch adds support for LLVM 15 and 16 by adding support for opaque
pointers, which are described in https://llvm.org/docs/OpaquePointers.html.  I
have also added a test case involving LLVM bitcode using opaque pointers to
kick the tires and ensure that the basics work as expected.

For the most part, this is a straightforward process, as most uses of pointer
types in SAW already do not care about pointee types. There are some
exceptions, however:

* The `typeOfSetupValue` function, as well as several places that use this
  function, scrutinize pointee types of pointers, which would appear to fly in
  the face of opaque pointers. I attempt to explain in #1876 which this is
  actually OK for now (although a bit awkward).
* The `llvm_boilerplate`/skeleton machinery does not support opaque pointers
  at all. See #1877.
* The `llvm_fresh_expanded_val` command does not support opaque pointers at
  all. See #1879.

This patch also bumps the following submodules to bring in support for opaque
pointers:

* `llvm-pretty`: GaloisInc/llvm-pretty#110
* `llvm-pretty-bc-parser`: GaloisInc/llvm-pretty-bc-parser#221
* `crucible`: GaloisInc/crucible#1085

This also bumps the `what4` submodule to bring in the changes from
GaloisInc/what4#234. This isn't necessary to support opaque pointers, but it
_is_ necessary to support a build plan involving `tasty-sugar-2.2.*`, which
`llvm-pretty-bc-parser`'s test suite now requires.
RyanGlScott added a commit that referenced this issue Jun 1, 2023
yav pushed a commit that referenced this issue Jun 16, 2023
This patch adds support for LLVM 15 and 16 by adding support for opaque
pointers, which are described in https://llvm.org/docs/OpaquePointers.html.  I
have also added a test case involving LLVM bitcode using opaque pointers to
kick the tires and ensure that the basics work as expected.

For the most part, this is a straightforward process, as most uses of pointer
types in SAW already do not care about pointee types. There are some
exceptions, however:

* The `typeOfSetupValue` function, as well as several places that use this
  function, scrutinize pointee types of pointers, which would appear to fly in
  the face of opaque pointers. I attempt to explain in #1876 which this is
  actually OK for now (although a bit awkward).
* The `llvm_boilerplate`/skeleton machinery does not support opaque pointers
  at all. See #1877.
* The `llvm_fresh_expanded_val` command does not support opaque pointers at
  all. See #1879.

This patch also bumps the following submodules to bring in support for opaque
pointers:

* `llvm-pretty`: GaloisInc/llvm-pretty#110
* `llvm-pretty-bc-parser`: GaloisInc/llvm-pretty-bc-parser#221
* `crucible`: GaloisInc/crucible#1085

This also bumps the `what4` submodule to bring in the changes from
GaloisInc/what4#234. This isn't necessary to support opaque pointers, but it
_is_ necessary to support a build plan involving `tasty-sugar-2.2.*`, which
`llvm-pretty-bc-parser`'s test suite now requires.
yav pushed a commit that referenced this issue Jun 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs design Technical design work is needed for issue to progress subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm type: enhancement Issues describing an improvement to an existing feature or capability
Projects
None yet
Development

No branches or pull requests

1 participant