Fix reporting traps (faults) to GDB in SE mode

[janvrany]

This addresses #123

[shingarov]

I believe it should be as @janvrany says, and empirically, it happens to be so on every physical RISC-V machine I have around here.

Still, there may be some reason why we are both wrong; @gabemblack what was your rationale for adding lines 167, 168?

[janvrany]

Looking at failed test, I do not really understand what went wrong... Has anyone any idea?

[powerjg]

I think the VM running the tests died. Can you rebase and force push to update the branch? This will kick off the tests again.

[shingarov]

Well I did a CI re-run yesterday and it didn't make any difference. So yeah, very strange.

[powerjg]

Ah, it's hitting a timeout. I'm not totally sure why... I would try running the test that it failed on timing-cpu_2-cores_no_cache_DualChannelDDR4_2400_arm_boot_test_to-tick-ALL-x86_64-opt

@mkjost0, do you have any suggestions on diagnosing this?

[janvrany]

@powerjg I did run

./build/ALL/gem5.debug -d /tmp/gem5out532w5i9e -re --silent-redirect tests/gem5/arm_boot_tests/configs/arm_boot_exit_run.py --cpu timing --num-cpus 2 --mem-system no_cache --dram-class DualChannelDDR4_2400 --resource-directory tests/gem5/resources --tick-exit 10000000000

on my machine and it terminated successfully after ~20 secs.

[powerjg]

Let's see if it works this time. Maybe we got unlucky and ran on a really slow CI core or something.

[janvrany]

@powerjg I think it got stuck again. Is there a way I can run a single testcase

timing-cpu_2-cores_no_cache_DualChannelDDR4_2400_arm_boot_test_to-tick-ALL-x86_64-opt

on my machine? (I realized that what I run above was problably the previous one)

[mkjost0]

The smallest unit of test we can run is by SuiteUID, which you can run by using ./main.py run --skip-build --uid SuiteUID:tests/gem5/arm_boot_tests/test_linux_boot.py:timing-cpu_2-cores_no_cache_DualChannelDDR4_2400_arm_boot_test_to-tick-ALL-x86_64-opt -vvv However, it looks like the command you ran above should accomplish the same thing as running this command.

[janvrany]

@mkjost0 Thanks. I tried that but still, "works for me".

I'm not sure what else to try locally, so let me just force-push one commit at time, starting with no-change commit, to see what happens.

[janvrany]

OK, so it looks like commit 7e64e7a is causing the hangup.

In theory that change may cause infinite loop (and therefore CI timeout) for RISC-V SE workloads if that workload depends on (incorrect) behavior of PC being increased before reporting trap.

However:

• regardless of PC value, invokeSE() is going to panic() so it should not matter and
• the that that hangs is ARM, so change in RISC-V should not affect it.

So, I do not understand that's going on here and out of ideas how to debug it.

[janvrany]

Ah! It is not ARM test that hangs, it is indeed RISC-V test that hangs - only the CI output is truncated! Now I can debug it.

Note to myself: this is what fails:

./build/ALL/gem5.opt --debug-flags=Exec ./tests/gem5/asmtest/configs/simple_binary_run.py rv64samt-ps-sysclone_d atomic riscv --num-cores 4 --resource-directory ./tests/gem5/resources

[powerjg]

Maybe we should make this PR be just the power change. I wonder if the gdb issue on RISC-V may be a different problem/solultion.

[rogerchang23424]

I think move the code section to SyscallFault::invokeSE(ThreadContext *tc, const StaticInstPtr &inst) will pass to test CI

[janvrany]

@rogerchang23424 Thanks, this is exactly what I did.

[janvrany]

OK, I did what @rogerchang23424 suggested and now all checks pass. I think this is ready for review now.

[shingarov]

Wait, what?

janvrany added a commit to janvrany/MachineArithmetic that referenced this pull request 16 hours ago

What does this have to do with janvrany/MachineArithmetic@81b31f1 ??

[janvrany]

What does this have to do with janvrany/MachineArithmetic@81b31f1 ??

Ah, sorry! Indeed this is completely unrelated, I just accidentally pasted wrong URL into commit message of MA. Fixed now.