commits
| 2026-01-04 | Merge branch 'float-compare' | Sören Tempel |
| 2026-01-04 | README.md: Update status | Sören Tempel |
| 2026-01-04 | quebex: Rename integer comparison types/functions for consistency | Sören Tempel |
| 2026-01-04 | quebex: Support FloatCmpOp | Sören Tempel |
| 2026-01-04 | quebex-syntax: Dedicated parsing of floating point comparisons | Sören Tempel |
Clone the repository to access all 409 commits.
README
A work-in-progress software analysis framework built around the QBE intermediate language.
Motivation
Existing analysis frameworks are predominantly built around LLVM. Unfortunately, LLVM is a fast-moving target with constant changes and updates to its intermediate representation. Therefore, tooling built on LLVM often requires dated LLVM versions (e.g., KLEE currently recommends LLVM 13 released in 2022). Obtaining these LLVM versions can be cumbersome and often hinders employment of these tools. To overcome these issues, maintainers of analysis tooling need to constantly invest time to catch up with LLVM releases instead of focusing on improving their analysis framework.
In order to reduce the maintenance burden, this project attempts to investigates the utilization of another intermediate language for software analysis: QBE. QBE is a much smaller-scale project than LLVM and thereby offers a higher degree of stability. Further, QBE is simpler than LLVM (e.g., providing fewer operations) and thereby eases the implementation of analysis techniques. Nonetheless, there exist compiler frontends that can emit a representation in the QBE intermediate representation (which can then be analyzed using quebex!). For example, SCC, cproc, or the Hare compiler.
Status
I currently consider this a vertical prototype. A lot of the desired
functionality is already there, but not fully developed. Presently, it
covers the majority of QBE features needed for medium-complexity QBE
programs (e.g., as emitted by cproc). Notably, proper support for
unions and variadic functions is missing. In terms of analysis features,
the implementation presently focuses on dynamic analysis techniques
(primarily symbolic
execution). Unfortunately, there is basically no documentation for
the API and the provided command-line frontends (quebex and
quebex-symex) are presently very basic.
Architecture
This project provides a formal, yet executable, description of the
QBE intermediate language. Currently, it targets v1.2 of the QBE
specification. The syntax is specified using literate
Haskell and parser
combinators in the quebex-syntax library. The language
semantics are expressed in a modular way by distinguishing abstract and
actual semantics. Abstract semantics of the QBE language are
described in terms of a Simulator monad (i.e., an abstract monad). This monad
must then be instantiated, whereby actual semantics are
specified. Presently, the following instantiations are supported:
- Concrete semantics, provided by
Language.QBE.Simulator.Default.State. This is useful for simulation of the QBE intermediate language. - Symbolic
(more specifically concolic)
semantics, provided by
Language.QBE.Simulator.Concolic.State. This is intended for automated software testing using symbolic execution.
The abstract description of the QBE semantics, in terms of the
Simulator monad, and its concrete instantiation are
provided by the quebex library. The symbolic semantics are
implemented by a separate quebex-symex library. Additional
semantics can be implemented by building on top of these existing
Haskell libraries.
Further, executable programs are provided by the
quebex-cli component. Presently the following executable
program components are available:
quebex: A simulator for QBE programs built on top of the concrete semantics.quebex-symex: An automated software testing tool facilitating the symbolic semantics.
These program components can be used directly on QBE input programs.
Installation
After cloning the repository, individual components can be installed
using cabal install. However, presently specific GHC
versions are required; therefore, installation using Guix is recommended. For example, in
order to install the quebex-cli component using Guix:
$ guix time-machine -C .guix/channels.scm -- install -L .guix/modules/ quebex-cli
Afterwards, if Guix is configured correctly, the aforementioned
program components (quebex and quebex-symex)
should be available in your $PATH. The following section
demonstrates usage of these components.
Demonstration
This framework is primarily intended to be used as a library, allowing the implementation of both static and dynamic analysis techniques based on QBE. Presently, it focuses on dynamic analysis, and sufficient documentation of the library interface is still lacking. Nonetheless, it is already capable of executing QBE representations of medium-complexity C code (e.g., as emitted by cproc). In order to experiment with the current capabilities, the following subsections demonstrate utilization of the aforementioned program components.
Concrete Execution
Consider the following “Hello, World!” program:
#include <stdio.h>
int main(void) {
puts("Hello, World!");
return 0;
}In order to concretly execute this program using quebex,
we need to obtain an equivalent representation in QBE. To this end, we
can invoke the cproc compiler as
follows:
$ cproc -emit-qbe hello.c
The resulting QBE file can then be executed with the concrete semantics using:
$ quebex hello.qbe
Hello, World!
Note that quebex is only able to invoke the
puts(3) function because it intercepts its execution,
providing a “simulated” version of it. Presently, only a limited amount
of standard library functions are intercepted in this way. As such,
interactions with the file system or more complex output functions
(e.g. printf(3)) are currently not supported.
Symbolic Execution
Symbolic execution is a dynamic software analysis technique that explores reachable program paths based on a symbolic input variable. For example, consider the following C program:
#include <stdio.h>
#include <stddef.h>
extern void quebex_symbolic_array(void *ptr, size_t nelem, size_t elsiz, const char *name);
int main(void) {
puts("<path>");
int a;
quebex_symbolic_array(&a, 1, sizeof(a), "a");
if (a == 42) {
puts("you found the answer");
} else {
puts("not the answer");
}
puts("</path>");
return 0;
}This program can be compiled using cproc as follows:
$ cproc -emit-qbe example.c
The resulting QBE representation (example.qbe) can be
symbolically executed using quebex:
$ quebex-symex example.qbe
This will yield the following output:
<path>
not the answer
</path>
<path>
you found the answer
</path>
Amount of paths: 2
This tells us that quebex found two paths through our program based
on the symbolic variable a. In the future, it will be
possible to obtain test inputs for each path in a standardized format
using quebex-symex, which can then be used to automatically
generate
high-coverage tests. However, for now the focus is on improving the
library, not the command-line interface.
Design Goals
This project is intentionally written in a simple subset of the Haskell programming language. It should be usable by anyone with a basic Haskell background (e.g., as obtained by reading Learn You a Haskell for Great Good!). Further, the project should require minimal long-term maintenance and should also support older GHC versions. Therefore, it uses the GHC2021 language standard and avoids usage of additional language extensions. Further, whenever possible, dependencies on external libraries that are not bundled by GHC must be avoided.
Development
Code should be formatted using ormolu. Git hooks performing several sanity checks, including ensuring the proper code formatting, are available. These hooks can be enabled using:
$ git config --local core.hooksPath .githooks
Further, a Guix environment for development purposes can be obtained using:
$ guix time-machine -C .guix/channels.scm -- shell -L .guix/modules/ -m .guix/manifest.scm
License
This project uses the REUSE Specification to indicated used software license.