Roman Popov

Many commercial SystemC tools have SystemC-specific profilers measuring runtimes of SC processes. On Windows I usually use Visual Studio built-in profiler. I don't have experience with profiling on Linux.

In general, you can use profiler tool to understand where hotspots are. Your code snippet is incomplete, so it is impossible to say anything.

Each shared library or executable has its own copy of static variables. So, if part of your application links SystemC dynamically, and other part links SystemC statically, the result is that you have 2 conflicting SystemC kernels in your application. So you have two options: - Use shared SystemC library everywhere - Use static linking everywhere

Well, compiler error is self-explanatory. I see this particular issue is fixed even in SystemC 2.3.0

SystemC 2.2 is quite old, may be incompatible with modern compilers. Why not to use SystemC 2.3.3 ?

I see at least 1 bug in code sample: for (auto val : var.read()) here you create copies of vector elements on a stack of your function. And then pass references to them into SystemC kernel. So those will be dangling references one you return from your sc_trace overload. Change to: for (auto & val : var.read())

Compiler already shown you where is the error and how to fix it. SystemC is a C++ library, you will need to learn C++ and get comfortable with g++ compiler before digging into SystemC.

VCS invokes g++ automatically. But this is correct, sc_main is missing.

This is correct, you cannot trace dynamic data structure. This is not even a SystemC limitation, but limitation of VCD waveform dump in general. VCD does not allow to add/remove signals to waveform dynamically. So usually you have two options : 1) If maximum capacity is known in advance and is small, you can create your own "list" that utilizes statically sized array as a storage: template<typename T> struct my_list_item { bool has_value = false; T value; } template<typename T, size_t MAX_SIZE> class my_list { std::array<my_list_item, MAX_SIZE> storage; // ... } 2) If maximum size is large or unknown, but it is sufficient for you to trace only head and tail of the list, you can have a copy of tail and head that is updated on every push and pop: class my_list { std::list<T> storage; my_list_item head_copy; my_list_item tail_copy; //... custom push pop }

Looks like XY problem to me. If you need pointer to event, use pointer.

Interesting, I'm not an expert in CMake, but even with existing CMakeLists.txt when I build my application SystemC include directory is recognized automatically as system headers: And as a result I don't receive any warnings about issues in SystemC headers.

You forgot ";" here: using namespace std;

Then I have no idea. Set breakpoint on this report and analyze why it gets there. From my perspective your code sample should work without Warnings.

I've reproduced the issue on Centos7. Preliminary it looks like a misuse of mprotect on memory allocated with new. So as a workaround commenting out stack protection section should work. Since I don't have enough linux system programming expertise I will bring it to accellera wg discussion before submitting a fix to systemc repo. Thanks a lot for reporting this and spending your time on investigation!

I was not able to reproduce. What g++ version do you use? Can you provide any example that reproduces the problem? I don't see that path, which line of code?