Inserting existing software into TLM frame

[Liyuan]

Hi 

I have a long story about using Systemc TLM.

I am having some trouble trying to embed our existing software (including driver) into the TLM frame.

Originally I called the application function in an SC_THREAD and wanted to let the driver function access tlm socket.

But our software and driver are shared libraries and can not see the upper layer socket which reside in a SC_MODULE. Besides I don't want to change the existing libraries and pass the variables or function pointers (like how sockets really do) down to the driver.

So I changed my mind and created another SC_THREAD to receive the tlm_generic_payload from the first one. I used a sc_fifo (dynamic sensitivity) for them to communicate. To achieve this I have to declare the fifo global in the driver. And I need to link the libsystemc.a in the shared library of driver (libsystemc.so requires the sc_main function).

After everything is cleared and compilation is passed, I get this error message at the end of running phase.

double free or corruption (fasttop): ...
======= Backtrace: =========
...
======= Memory map: ========
...
Aborted (core dumped)

It seems that as long as I access global variables or functions in the driver, this happens (I can still get the variable).

I drew a simple schematic diagram to illustrate my project.

My Question:

I used static systemc library in the driver and a shared systemc library in the upper application, could this be the problem?

How can I solve my problem?

I believe that developing TLM model with software is a general case, is there a pattern to do this in a systematic way without changing the software (only interface) too much?

Was I primarily wrong at the beginning?

 

Any interpretation or suggestion would be appreciated.

Liyuan

[Liyuan]

ok if I use static library for both of them, the error disappears.

Still looking forward to some useful comments~

[Roman Popov]

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

[Liyuan]

On 1/20/2020 at 9:13 PM, Roman Popov said:

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

thanks so much.