Sartorato Giovanni Alberto
[email protected]
Person code: 10678032
For this project ASPIS was forked to support C++ compilation and tested on multiple benchmarks. The fork can be found in my repository. The following are the changes that were implemented:
This issue occurred when attempting to insert calls to external error handler functions dataCorruptionHandler
and SigMismatch_Handler
, during the EDDI,RASM and CFCSS passes.
LLVM generates mangled names for functions, especially in C++ code to support features such as function overloading and namespaces. However, when trying to insert calls to dataCorruptionHandler
or SigMismatch_Handler
, the pass used the unmangled version of the function name. The linkage lookup mechanism was unable to resolve the mangled function names, causing the pass to fail when inserting the call.
The functions mapFunctionLinkageNames
and getLinkageName
were added to utils.
mapFunctionLinkageNames
is called at the beginning of every pass and creates a map between the original function name and its mangled names (since there may be more than one).
Then, when dataCorruptionHandler
and SigMismatch_Handler
need to be inserted, the correct mangled name is retrieved using getLinkageName
.
The flag -lstdc++
was added to Clang options in aspis.sh
to enable C++ compilation if at least one of the input files is a C++ file.
alloca
instructions for exception handling were being duplicated in EDDI, causing multiple allocations for exceptions and leading to control flow errors.
In RASM, when checking the number of successors a block has to compute and update a runtime signature used for control flow integrity, basic blocks with an invoke
as the terminator were treated as having multiple successors, which complicated control flow.
A check was added to force the number of successors to 1 by overriding numSuccessors
if the terminator is an exceptional terminator (such as invoke
, which branches based on whether an exception is thrown). This ensures that exception handling is treated uniformly and simplifies the process of updating the runtime signature.
In RASM and CFCSS, landing pads were treated like regular blocks, and verification instructions were inserted before the first instruction. This caused compilation failures because the first instruction in a landing pad must be the landing pad instruction itself.
A special case for landing pads was created in createCFGVerificationBB
in RASM and CFCSS. Instead of inserting verification instructions before the first instruction, a store instruction is created at the first insertion point, writing randomNumberBB
into the memory pointed to by RuntimeSig
.
In CFCSS::sortBasicBlocks
, blocks with an invoke
terminator were treated like other blocks, and a conditional branch was created. However, when a basic block ends with an InvokeInst
, exception handling is already managed by the InvokeInst
, so no additional conditional branching is necessary.
All changes were tested on multiple benchmarks. In particular, in examples/cpp-benchmarks
, full_test.cpp
was added to test various C++ programming features, including:
-
Basic Functions (with overloading);
-
Classes and inheritance (member functions, constructors, virtual functions, inheritance and polymorphism with DerivedClass);
-
Templates;
-
Recursion;
-
Exception handling.