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

crucible-llvm: Generalize LLVMOverride's ext parameter #1184

Conversation

langston-barrett
Copy link
Contributor

Previously, the OverrideSim action for an LLVMOverride was assumed to have a fixed ext parameter, namely, LLVM. While this is intuitively appealing, it turns out not to be necessary. This is because there are only a few operations in the OverrideSim monad that make essential use of the ext parameter, such as registering or calling a CFG in the given language extension. These operations are unlikely to be used when defining, e.g., overrides for libc functions.

The motivation for generalizing the parameter is to enable the reuse of LLVMOverrides in other Crucible language extensions that make use of the LLVM memory model, namely, Macaw.

@langston-barrett
Copy link
Contributor Author

Ah, whoops, this breaks something in UC-Crux.

@langston-barrett
Copy link
Contributor Author

Indeed, UC-Crux does actually create LLVMOverrides that use callCFG to call LLVM CFGs. The way I see it, there are two paths forward:

  • Make ext a type parameter of LLVMOverride. Then the overrides in Crucible-LLVM would be polymorphic over ext, while the ones in UC-Crux would fix ext to LLVM. This is the most flexible solution, as it allows each override to choose a particular extension if it needs it, or not if not.
  • Tear this functionality out of UC-Crux. As UC-Crux is not very useful since the introduction of opaque pointers and is unlikely to be modified to be so (see Support opaque pointers in crucible-llvm and uc-crux-llvm #1075), and the "check" overrides in question aren't a core part of its functionality, this is also fairly appealing.

@RyanGlScott any thoughts?

@RyanGlScott
Copy link
Contributor

I am fine with either option, but option (1) sounds slightly more appealing since we want to make LLVMOverride more like TypedOverride anyway (#1138), and TypedOverride is already parameterized by ext.

@kquick
Copy link
Member

kquick commented Mar 21, 2024

I'd also vote for option 1: I think it's probably too early to give up on uc-crux-llvm's potential.

Previously, the `OverrideSim` action for an `LLVMOverride` was
assumed to have a fixed `ext` parameter, namely, `LLVM`. While this is
intuitively appealing, it turns out not to be necessary. This is because
there are only a few operations in the `OverrideSim` monad that make
essential use of the `ext` parameter, such as registering or calling a
CFG in the given language extension. These operations are unlikely to be
used when defining, e.g., overrides for libc functions.

The motivation for generalizing the parameter is to enable the reuse of
`LLVMOverride`s in other Crucible language extensions that make use
of the LLVM memory model, namely, Macaw.
Copy link
Contributor

@RyanGlScott RyanGlScott left a comment

Choose a reason for hiding this comment

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

Thanks! It would be worth advertising this change in the crucible-llvm changelog, as this change will impact saw-script. Otherwise, LGTM.

@langston-barrett langston-barrett merged commit 0d26eb4 into GaloisInc:master Mar 22, 2024
31 checks passed
@langston-barrett langston-barrett deleted the lb/crucible-llvm-override-ext branch March 22, 2024 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants