-
Notifications
You must be signed in to change notification settings - Fork 69
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_boilerplate
/function skeletons
#1877
Labels
needs design
Technical design work is needed for issue to progress
subsystem: crucible-llvm
Issues related to LLVM bitcode verification with crucible-llvm
tech debt
Issues that document or involve technical debt
type: enhancement
Issues describing an improvement to an existing feature or capability
Milestone
Comments
RyanGlScott
added a commit
that referenced
this issue
May 31, 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. 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
May 31, 2023
See #1877 for further discussion.
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.
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.
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
tech debt
Issues that document or involve technical debt
type: enhancement
Issues describing an improvement to an existing feature or capability
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 typeptr
, 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:llvm-pretty
PR to support opaque pointers: More complete support for opaque pointers (required for LLVM 15+) llvm-pretty#110llvm-pretty-bc-parser
PR to support opaque pointers: More complete support for opaque pointers (required for LLVM 15+) llvm-pretty-bc-parser#221crucible
PR to support opaque pointers: More complete support for opaque pointers (required for LLVM 15+) crucible#1085While most parts of SAW now fully support opaque pointers, there is one part of SAW that cannot handle them at the moment: the
llvm_boilerplate
command. This is becausellvm_boilerplate
inspects the skeletons of LLVM function types to determine what boilerplate code to generate, and this code necessarily inspects pointee types. Look at this code to see what I mean:saw-script/src/SAWScript/Crucible/LLVM/Skeleton.hs
Lines 99 to 104 in 79f69bf
This code records which types are pointers and records the pointee types. Later, these
TypeSkeleton
s are used to generate SAWScript code, and different code is generated for pointers that makes use of the pointee types:saw-script/src/SAWScript/Crucible/LLVM/Boilerplate.hs
Lines 65 to 76 in 79f69bf
saw-script/src/SAWScript/Crucible/LLVM/Boilerplate.hs
Lines 104 to 113 in 79f69bf
It is not obvious how to adapt this code to work with opaque pointers, which lack pointee types entirely. SAW's
llvm_alloc
command requires a type to use, so where would we get this type from? Some half-baked ideas I have include:function_skeleton
command that allows users to specify what the types of pointers' underlying memory should be. (I'm unclear on what the design for this should look like.)Because I am unclear on what the right approach should be, I have opted to make SAW error out whener it attempts to construct a skeleton for an opaque pointer type.
The text was updated successfully, but these errors were encountered: