Save ChiselDB before LightSSS failure replay

[Ivyfeather]

Root cause

ChiselDB stores records in an in-memory SQLite database and only exports them from Emulator::~Emulator(). With LightSSS fork debugging enabled, the parent waits for the replay child before reaching save_db(). If the replay child hangs, the parent is eventually killed and the database is lost.

Change

Save the parent ChiselDB database before waking the LightSSS replay child on failure. Track whether that early save occurred so the destructor does not save the same database again if replay returns.

The existing final-save path remains in place for:

• non-fork runs
• successful fork-enabled runs
• fork replay children

Impact

Failed simulations retain the parent ChiselDB records even when the replay child does not terminate.

Validation

• Confirmed the branch is one commit ahead of master and modifies only src/test/csrc/emu/emu.cpp.
• Checked preprocessor/path behavior with and without ENABLE_CHISEL_DB, for fork parents, fork children, and non-fork runs.
• Full build and a hanging LightSSS replay were not run locally because this workspace does not contain a difftest checkout; CI or maintainer testing is still required.

[poemonsense]

Should ChiselDB use the similar logic with waveform?

For waveform, if LightSSS is enabled, dump_wave is disabled by default and only dumped at child process. Similarly, is it better to dump ChiselDB only at child process?

[Ivyfeather]

Should ChiselDB use the similar logic with waveform?

For waveform, if LightSSS is enabled, dump_wave is disabled by default and only dumped at child process. Similarly, is it better to dump ChiselDB only at child process?

Sure. I will check waveform logic that works with LightSSS and make further modifications.

[Ivyfeather]

This change was originally introduced to investigate a CI issue. When the error occurred and LightSSS attempted to fork, both the parent and child processes became stuck and made no further progress. The emulator could only be killed after the CI timeout, or by manually cancelling the job, and no DB output was produced.

To determine whether this was a cache-related issue, we added this change so that the parent process would emit the DB earlier and make debugging possible.

However, we later found that the hang in the LightSSS fork scenario was likely caused by the newly added MMA-checking thread, which had an issue in forked processes. This has been fixed in commit 54d448f.

Therefore, this PR is no longer necessary and will be closed.