Jump to content


  • Content count

  • Joined

  • Last visited

  1. Backtrace with sc_report_error()

    Thanks for all of the suggestions. It turns out that the file name and line number in the output that I originally posted can be used to set a breakpoint and from there a call stack can be dumped (with bt). This approach is a bit like what Roman had suggested. I was also able to get sc_report_handler::set_action() to work. It's great to have all of the options suggested here.
  2. Backtrace with sc_report_error()

    1. Doesn't try/catch block work only within that thread? 2. Can you kindly point me to documentation on how to change the default action of SC_ERROR? I couldn't find it in the UserGuide and did not find useful googling the internet. I would like to change it to SC_ABORT and change the abort handler to use Boost to dump the stack (as Roman suggested above). Yes, SC_REPORT_ERROR() is being used and in the output that I showed above, it is identifying a system C include file as the place where SC_REPORT_ERROR() is called.
  3. Does anyone know if it is possible to see the call stack when sc_report_error() is called? Here's an example of the output under lldb when my systemC program is run. The call to sc_report_error() causes the program to exit, leaving no call stack. Error: (E5) out of bounds In file: /usr/local/systemc/include/sysc/datatypes/bit/sc_bit_proxies.h:2487 In process: x.y.z @ 5 ns Process 10618 exited with status = 1 (0x00000001) Is there a configuration flag to cause sc_report_error() to not cause an exit()? Thanks in advance for your help.