SystemC catching/rethrowing standard exceptions is harmful?

[Roman Popov]

Disclaimer: I'm not an expert in C++ exceptions field.

I've noticed that SystemC catches / re-throws standard exceptions. Why it does so?

In practice that complicates debugging: instead of having a stacktrace to place where exception was originally thrown, I have a stack trace to place where systemc catches/rethrows it, which is not helpful at all.

Should it be better to only catch sc_report?

[Eyck]

Hi,

I'm not an implementer of the reference simulator but as far as I can judge the re-throw is used to find a more specific type of exception (since sc_elab_and_sim() just uses a catch-all) and uses sc_handle_exception() to convert it into an sc_report so it can be handled by the SystemC reproting system. Actually I agree it would be better to handle it directly in sc_elab_and_sim() but this would duplicate code.

A side note rgd. debugging: if you use gdb there is a command 'catch throw' which stops execution right at the point where the (original) exception is thrown. This comes pretty handy in such cases.

Best regards

[Philipp A Hartmann]

Hi Roman,

I can give some background here, as I'm guilty of the current implementation.

The kernel also needs to handle exceptions that are escaping SystemC thread processes.  These are originally thrown in a different stack and still need to be propagated to sc_main, i.e. the main thread in order to be able to still catch the exceptions there in user code.  The propagation across stacks has to be done by catching in one stack and rethrowing in another.

That said, exception handling not only covers sc_report, but also arbitrary exception types escaping sc_main or a SystemC thread.  We don't want to cause std::terminate to be called in case of uncaught exceptions, but want to properly propagate, catch and wind down the simulation.  Therefore, all exceptions are translated to standard sc_report objects before cross-stack propagation and are finally handled outside of sc_main.

For consistency, the translation to sc_report is done for both, thread and method processes: It's an error, if an exception escapes a SystemC process and errors are reported as sc_report (and routed through the report handler) in SystemC.  Users can catch the original exceptions themselves by adding catch blocks to sc_main and their SystemC processes.

Hope that helps,
  Philipp

[Roman Popov]

Thanks for explanation. In some scenarios std::terminate is what you actually want, since some exceptions are actually programming bugs, like for example out-of-bounds access in std::vector::at. And in this case you want debugger to show you a stack trace to the point where exception was originally thrown. According to this post from Herb Sutter : https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-standards-meeting-rapperswil/ such kind of exceptions will migrate to contracts in future.  So it seems like a C++ standard library design flaw, rather than SystemC problem.   

A side note rgd. debugging: if you use gdb there is a command 'catch throw' which stops execution right at the point where the (original) exception is thrown. 

This will break on each SystemC thread reset, since they are implemented using exceptions.  Some other more precise mechanism required.  'catch throw std::out_of_range' works for std::vector::at. But catching base classes, like 'catch throw std::logic_error' does not  .

[Philipp A Hartmann]

On 9/27/2018 at 7:23 PM, Roman Popov said:

This will break on each SystemC thread reset, since they are implemented using exceptions.  Some other more precise mechanism required.  'catch throw std::out_of_range' works for std::vector::at. But catching base classes, like 'catch throw std::logic_error' does not 

You may be able to break on __cxa_throw explicitly and add a condition to the breakpoint to filter out unwanted exception types (e.g. sc_unwind_exception for  thread resets).

[Allen yang]

On 9/27/2018 at 9:50 PM, Philipp A Hartmann said:

Hi Roman,

I can give some background here, as I'm guilty of the current implementation.

The kernel also needs to handle exceptions that are escaping SystemC thread processes.  These are originally thrown in a different stack and still need to be propagated to sc_main, i.e. the main thread in order to be able to still catch the exceptions there in user code.  The propagation across stacks has to be done by catching in one stack and rethrowing in another.

That said, exception handling not only covers sc_report, but also arbitrary exception types escaping sc_main or a SystemC thread.  We don't want to cause std::terminate to be called in case of uncaught exceptions, but want to properly propagate, catch and wind down the simulation.  Therefore, all exceptions are translated to standard sc_report objects before cross-stack propagation and are finally handled outside of sc_main.

For consistency, the translation to sc_report is done for both, thread and method processes: It's an error, if an exception escapes a SystemC process and errors are reported as sc_report (and routed through the report handler) in SystemC.  Users can catch the original exceptions themselves by adding catch blocks to sc_main and their SystemC processes.

Hope that helps,
  Philipp

 

Hi Philipp,

    I met this problem two days ago. I  use `catch throw` and find code bug. And I want to kown how to add catch blocks to sc_main and my our SystemC process?