RASM signature checks fail in multithreaded code despite using thread_local globals

[gabrielekarra]

Description:
When running the RASM pass on a simple multithreaded test (four threads all calling a worker(int) loop), RASM immediately triggers a SigMismatch_Handler even after converting both runtime_sig and run_adj_sig into thread_local globals. In other words, each thread has its own copy of the two signature variables, yet RASM still complains that the runtime signature does not match inside worker(). This suggests that RASM’s design currently does not support verifying control‐flow inside true multithreaded functions.

Steps to Reproduce:

1. Execute test threads.cpp in PR
2. Generate LLVM IR: clang++ -O0 -g -emit-llvm -S -o threads.ll threads.cpp
3. Run RASM: opt -load-pass-plugin build/passes/libRASM.so \ -passes=rasm-verify \ -S threads.ll -o instrumented.ll
4. Compile and link:
   llc -filetype=obj instrumented.ll -o threads.o clang++ -g -O0 -no-pie threads.o -o threads_test
5. Run: ./threads_test
6. Immediately prints: ASPIS error: Signature mismatch detected

Actual Behavior:
RASM fails inside worker(int) with a signature mismatch, even though:

• Both runtime_sig and run_adj_sig are declared thread_local.
• Each thread has its own private copy of those globals.
  Breaking at SigMismatch_Handler confirms that the failure happens within the RASM‐inserted verification basic block in worker().

Expected Behavior:
With runtime_sig and run_adj_sig marked thread_local, each thread’s instrumentation state should remain isolated. RASM should be able to verify the control‐flow inside worker() in each thread without interference from other threads.

No SigMismatch_Handler error should occur purely due to multithreading.

Impact:

• Blocks use of RASM to verify multithreaded loops. Any code that spawns threads and then enters loops or per‐thread computations is currently impossible to verify under the RASM pass.
• Forces users either to disable RASM entirely for multithreaded functions or patch RASM manually.

Suggested Resolution:

1. Allow RASM to recognize thread_local global signatures and keep per‐thread signature state internally. That way, control‐flow checks within each thread do not collide.
2. Document a built‐in annotation (e.g., skip_rasm) so users can explicitly opt out a function from instrumentation rather than manually editing the pass.
3. If full multithreaded support is not intended, update the README or wiki to state that RASM does not support intraprocedural checks in functions launched by std::thread, and suggest users annotate or disable those functions.

Environment:

• Ubuntu 22.04
• LLVM/Clang 16

[davidebaroffio-polimi]

It appears that the issue only occurs when compiling with clang++. Using clang yields a DataCorruption, instead.