vasu_c Posted October 16, 2018 Report Share Posted October 16, 2018 Hi, I am seeing a similar issue as mentioned in the thread below with the tlm package shipped with SystemC-2.3.2 and SystemC-2.3.1. https://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200802&msg=msg00013.html Are the suggestions made by Alan the only options to work around this issue ? Would this be fixed in the official tlm release ? Thanks in advance for the help/suggestions. Quote Link to comment Share on other sites More sharing options...
maehne Posted October 16, 2018 Report Share Posted October 16, 2018 Thanks for providing this feedback on the SystemC PoC implementation! It would help if you could share some more details about the exact error messages as well as a minimal self-contained example exposing the problem you are observing. Then, we may discuss the issue more seriously. Quote Link to comment Share on other sites More sharing options...
vasu_c Posted October 17, 2018 Author Report Share Posted October 17, 2018 Hi, Thanks for the response. In lined is the test case that fails to compile. #include "tlm" #include "systemc.h" class slave : public sc_module { public: sc_port<tlm::tlm_fifo_get_if<int> > target_port; SC_HAS_PROCESS(slave); slave(sc_module_name nm) : sc_module(nm) { SC_THREAD(run); } void run() { for(int a = 0 ; a < 20 ; a++) { int b; target_port->nb_peek(b); std::cout << b << " "; } } }; Errors: test.cpp: In member function 'void slave::run()': test.cpp:17:17: error: request for member 'nb_peek' is ambiguous target_port->nb_peek(b); ^ In file included from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h:39:0, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h:23, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h:29, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm:26, from test.cpp:1: systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h:54:16: note: candidates are: bool tlm::tlm_fifo_debug_if<T>::nb_peek(T&, int) const [with T = int] virtual bool nb_peek( T & , int n ) const = 0; ^ In file included from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h:28:0, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h:39, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h:23, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h:29, from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm:26, from test.cpp:1: systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_core_ifs.h:116:16: note: bool tlm::tlm_nonblocking_peek_if<T>::nb_peek(T&) const [with T = int] virtual bool nb_peek( T &t ) const = 0; Quote Link to comment Share on other sites More sharing options...
Roman Popov Posted October 18, 2018 Report Share Posted October 18, 2018 Thanks for report. I will put this into SystemC bug tracker. Until it is fixed, you can use a workaround: target_port->tlm_get_peek_if<int>::nb_peek(b); Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted October 18, 2018 Report Share Posted October 18, 2018 Alternatively, as you don't seem to require the debug interface, you can change the port to: sc_port<tlm::tlm_get_peek_if<int> > target_port; Quote Link to comment Share on other sites More sharing options...
vasu_c Posted October 19, 2018 Author Report Share Posted October 19, 2018 Thank you so much Roman and Philipp. Appreciate the work around suggested. Please can I know which release would contain this fix ? Quote Link to comment Share on other sites More sharing options...
Roman Popov Posted October 19, 2018 Report Share Posted October 19, 2018 1 hour ago, vasu_c said: Thank you so much Roman and Philipp. Appreciate the work around suggested. Please can I know which release would contain this fix ? 2.3.3 will be released next week w/o a fix. So most likely next one after 2.3.3 Quote Link to comment Share on other sites More sharing options...
tjd Posted January 30, 2019 Report Share Posted January 30, 2019 Hate to bump an old, resolved thread, but I'm running into a linker issue using this work-around (systemc-2.3.1) The simple version is that I'm getting an error message of an "undefined reference to "tlm::tlm_nonblocking_peek_if<CustomType *>::nb_peek(CustomType *&) const" when using the implementation as suggested by Philipp for the port interface and Roman in the call. Any thoughts as to what might be causing this? I have included tlm.h, is that sufficient? Is there another library that needs linked in? Quote Link to comment Share on other sites More sharing options...
Roman Popov Posted January 31, 2019 Report Share Posted January 31, 2019 On 1/30/2019 at 10:24 AM, tjd said: Hate to bump an old, resolved thread, but I'm running into a linker issue using this work-around (systemc-2.3.1) The simple version is that I'm getting an error message of an "undefined reference to "tlm::tlm_nonblocking_peek_if<CustomType *>::nb_peek(CustomType *&) const" when using the implementation as suggested by Philipp for the port interface and Roman in the call. Any thoughts as to what might be causing this? I have included tlm.h, is that sufficient? Is there another library that needs linked in? This is strange, tlm_nonblocking_peek_if is an abstract class, so compiler should not allow you to construct it. Can you give small complete example reproducing the problem? Quote Link to comment Share on other sites More sharing options...
tjd Posted January 31, 2019 Report Share Posted January 31, 2019 Just generated one. There is a tarball attached that contains a producer, consumer, and a main that connects the two. Also included is a simple bash script with my compilation commands and the log generated from running the script where I've also appended the G++ version to it. tlm_ex.tar Roman Popov 1 Quote Link to comment Share on other sites More sharing options...
Roman Popov Posted January 31, 2019 Report Share Posted January 31, 2019 1 hour ago, tjd said: Just generated one. There is a tarball attached that contains a producer, consumer, and a main that connects the two. Also included is a simple bash script with my compilation commands and the log generated from running the script where I've also appended the G++ version to it. tlm_ex.tar Oh nice, seems my workaround was wrong. I did not know that qualified name lookup suppresses dynamic dispatch of virtual functions. https://en.cppreference.com/w/cpp/language/virtual Quote Virtual functions are member functions whose behavior can be overridden in derived classes. As opposed to non-virtual functions, the overridden behavior is preserved even if there is no compile-time information about the actual type of the class. If a derived class is handled using pointer or reference to the base class, a call to an overridden virtual function would invoke the behavior defined in the derived class. This behavior is suppressed if the function is selected using qualified name lookup (that is, if the function's name appears to the right of the scope resolution operator ::). C++ is full of such traps 🙂 Quote Link to comment Share on other sites More sharing options...
tjd Posted February 1, 2019 Report Share Posted February 1, 2019 Always fun for the lesser experienced C++ types (e.g., myself). Putting notes here in case anyone else runs into this: When declaring the port as a tlm_get_peek_if no workaround is necessary, thus, you can directly do target_port->nb_peek(x) . Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.