Roman Popov

Do you have SystemC compiled as DLL? Otherwise you have same issue as described here : https://forums.accellera.org/topic/6540-inserting-existing-software-into-tlm-frame/

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?

Also can you run make check after build to see if it is only your example that fails, or some bundled examples also fail.

I have no explanation. Can you please write the steps how you build SystemC library. Will try to install Centos7 on VM and reproduce your steps.

Did you probably forget to add wait() into consumer thread to suspend it after first read?

Here is how it is specified by standard: So it notified after each delta cycle where fifo was read. Can it be that your receiver does nb_read from empty fifo?

Also can you check if failing array in your test is indeed allocated in BSS? (Print values of p pointer before crashing)

Indeed, quote from that thread: So it could be that SystemC co-routine stack was allocated in BSS and setting mprotect on redzone failed. And the difference between CentOS and Ubuntu can be explained by difference in malloc implementation. So indeed can be a bug in SystemC. Can you comment-out assert in stack_protect function in SystemC kernel, rebuild it, rebuild your application and check if it works?

I don't have any CentOS machine now. I've run your example on SLES 11 with gcc 4.8 and it returned no errors. Also I don't understand how your code sample can detect memory corruption in SystemC, can you explain?

Probably SCTIME_CLOCKTIME expands to nothing in your case?

No, they are not equivalent. They notify different events: wait ( time ); // notify active thread == self-notification FIFO_write_event.notify (time); // notify FIFO_write_event