[BUG] Scarab fails assertion when running `clang` 10. about scarab HOT 2 CLOSED

Thanks for reporting this. I am going to divide you post into three parts and comment on each.

1. Scarab works fine when the assertion is commented out.

Scarab is probably not working fine when the assertion is commented out. Let me explain.

Scarab is divided into two parts, which we refer to as "the frontend" and "the backend". The frontend is a PIN based, instruction-level functional simulator that is responsible for actually executing the program. In your example, the frontend is the unit responsible for actually running clang and generating the resulting hello.out executable.

The backend is the microarchitecture timing model, which is responsible for modeling all aspects of the system (fetch, decode, ROB, DRAM, etc.). Decoupling the frontend and the backend provides Scarab with several advantages, which I will not touch on here. However, there is one unfortunate side effect: bugs in the backend (timing model) do not necessarily result in incorrect functional results (frontend). This is why, despite there being some issue in the backend, clang still runs correctly.

2. Scarab only runs statically linked binaries.

The link you sent to the LLVM Downloads Page only contains dynamically compiled versions of LLVM.

In theory, Scarab should be able to run dynamically linked executables, however in practice we have seen random crashes when running dynamically linked executables. We do not fully understand those crashes, so we decided to not support it while we roll out the main features of Scarab. There are no currently plans to fix these issues.

The easiest workaround here is to compile the LLVM binary statically. This may not be what is causing this particular issue, but it is certainly the first thing I would check.

3. Why else could the assert be firing?

Here is the million dollar question. I am not sure what the issue is without debugging Scarab; however I can help point you in the right direction. This assertion is perhaps one of Scarab's most common. It happens when the frontend sends the backend an instruction that the backend was not expecting (the fetch address is what the backend was expecting, the op address is what was sent from the frontend).

The first thing I would check is which of the two addresses is actually correct. That way the bug can be isolated to the frontend or backend. Easiest way to do this is to follow the direction to debug Scarab, making sure to enable debug mode for an instruction range that contains the assert. The assert message you pasted shows the instruction count when the assertion was fired (I=23546173). You can then look at the value of the PC for the op that was fetched just before the ASSERT and look into the clang binary to see what the actual next PC after that op should be.

Based on the value of the fetch address that is causing the ASSERT (0x7fffe...), it seems like the ASSERT is probably happening during some of the dynamically linked code. In that case, looking into the clang binary will not help you see what the actual next PC should be. Instead, you should enable debug in the frontend to get a trace of expected instructions. To do that, you need to compile the frontend for debug:

cd src/pin/pin_exec
make debug_print

This will print a trace to the pin.out log file that should give you a good sense of what the correct PC should be.

To limit the scope of the debug prints, add -debug_print_start_uid and -debug_print_end_uid to the scarab launch command:

./bin/scarab_launch.py --program "$CLANG hello.c" --param src/PARAMS.* --pintool_args="-debug_print_start_uid 29000000 -debug_print_end_uid 30000000"

You will probably need to fine tune the actual values of -debug_print_start_uid and -debug_print_end_uid to match the actual inst_uid values that occur during the assertion.

from scarab.

Closing this issue as there has been no activity in over a week. Feel free to open again if further issues arise.

from scarab.