My custom code with qt5 + qtquick2 in shared object

Carlos Delfino · 15 Aug 2021, 23:25

I'm writing a small shared object that is adapted for use in a simulator (iverilog) which loads it after being converted to a file called .vpi.

My proof of concept works when I use a common executable directly in qtcreator, but when I generate the shared object, using the same parameters to generate the executable, everything compiles correctly, but when the simulator loads the library I get the following error:

iverilog -o simulinho.vvp /home/carlosdelfino/workspace/RISCuinho/SIMULinho/simulinho.v && vvp -v -M. -msimulinho_vpi simulinho.vvp
Compiling VVP ...
simulinho_vpi:`./simulinho_vpi.vpi' failed to open using dlopen() because:
    ./simulinho_vpi.vpi: undefined symbol: _Z21qRegisterResourceDataiPKhS0_S0_.
 ... VVP file version 10.1 (stable)
/home/carlosdelfino/workspace/RISCuinho/SIMULinho/simulinho.v:3: Error: System task/function $hello() is not defined by any module.
/home/carlosdelfino/workspace/RISCuinho/SIMULinho/simulinho.v:4: Error: System task/function $openUI() is not defined by any module.
/home/carlosdelfino/workspace/RISCuinho/SIMULinho/simulinho.v:5: Error: System task/function $closeUI() is not defined by any module.
Compile cleanup...
 ... Linking
 ... Removing symbol tables
 ... Compiletf functions
simulinho.vvp: Program not runnable, 3 errors.
Makefile:359: recipe for target 'verilognize_vvp' failed
make: *** [verilognize_vvp] Error 3

final commands:

g++ -c -pipe -O2 -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_VERSION_TAGGING -DSIMULINHO_SHAREDLIB -D__SIMULINHO_DUMP__ -DQT_NO_DEBUG -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -fPIC -I../SIMULinho -I. -I/usr/lib/i386-linux-gnu -isystem /usr/include/iverilog -I../SIMULinho -isystem /usr/include/i386-linux-gnu/qt5 -isystem /usr/include/i386-linux-gnu/qt5/QtQuick -isystem /usr/include/i386-linux-gnu/qt5/QtGui -isystem /usr/include/i386-linux-gnu/qt5/QtQml -isystem /usr/include/i386-linux-gnu/qt5/QtNetwork -isystem /usr/include/i386-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I/usr/lib/i386-linux-gnu/qt5/mkspecs/linux-g++ -fstack-protector-strong -Wformat -Werror=format-security -Wextra -Wshadow -fdebug-prefix-map=/build/iverilog-3pPO9t/iverilog-10.1=. -g -o simulinho_vpi.o ../SIMULinho/simulinho_vpi.cpp && g++ --shared -pipe -O2 -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_VERSION_TAGGING -DSIMULINHO_SHAREDLIB -D__SIMULINHO_DUMP__ -DQT_NO_DEBUG -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB  -L/usr/lib/i386-linux-gnu -lvpi -lveriuser -lQt5Quick -lQt5Gui -lQt5Qml -lQt5Network -lQt5Core -lGL -lpthread  simulinho_vpi.o qrc_qml.o -o simulinho_vpi.so simulinho.o
../SIMULinho/simulinho_vpi.cpp: In function ‘int simulinho_ui_compiletf(char*)’:
../SIMULinho/simulinho_vpi.cpp:13:40: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int simulinho_ui_compiletf(char*user_data){
                                        ^~~~~~~~~
../SIMULinho/simulinho_vpi.cpp: In function ‘int simulinho_ui_calltf(char*)’:
../SIMULinho/simulinho_vpi.cpp:17:37: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int simulinho_ui_calltf(char*user_data){
                                     ^~~~~~~~~
../SIMULinho/simulinho_vpi.cpp: In function ‘int hello_compiletf(char*)’:
../SIMULinho/simulinho_vpi.cpp:27:33: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int hello_compiletf(char*user_data)
                                 ^~~~~~~~~
../SIMULinho/simulinho_vpi.cpp: In function ‘int hello_calltf(char*)’:
../SIMULinho/simulinho_vpi.cpp:32:30: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int hello_calltf(char*user_data)
                              ^~~~~~~~~
cp simulinho_vpi.so simulinho_vpi.vpi && objcopy --only-keep-debug simulinho_vpi.vpi simulinho_vpi.vpi.debug && objcopy --strip-debug simulinho_vpi.vpi && objcopy --add-gnu-debuglink=simulinho_vpi.vpi.debug simulinho_vpi.vpi

Repo from project: https://github.com/RISCuinho/SIMULinho/tree/first_vpi

jeremy_k · wrote on 15 Aug 2021, 23:25

@Carlos-Delfino said in My custom code with qt5 + qtquick2 in shared object:

My proof of concept works when I use a common executable directly in qtcreator, but when I generate the shared object, using the same parameters to generate the executable, everything compiles correctly, but when the simulator loads the library I get the following error:
iverilog -o simulinho.vvp /home/carlosdelfino/workspace/RISCuinho/SIMULinho/simulinho.v && vvp -v -M. -msimulinho_vpi simulinho.vvp

As a general formatting detail, it's a lot easier to read if individual commands aren't combined on a single line. The compiler invocation, for example makes it look like there is only a single invocation with the -c flag.

Compiling VVP ...
simulinho_vpi:`./simulinho_vpi.vpi' failed to open using dlopen() because:
./simulinho_vpi.vpi: undefined symbol: Z21qRegisterResourceDataiPKhS0_S0.
... VVP file version 10.1 (stable)

Have you tried running ldd on the library? I'm presuming this is Linux based on the i386-linux-gnu that appears a few times.

The missing symbol should be in libQt5Core.so

$ c++filt _Z21qRegisterResourceDataiPKhS0_S0_
qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)

https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qresource.cpp#n1011

Carlos Delfino · 16 Aug 2021, 00:44

@jeremy_k said in My custom code with qt5 + qtquick2 in shared object:

As a general formatting detail, it's a lot easier to read if individual commands aren't combined on a single line. The compiler invocation, for example makes it look like there is only a single invocation with the -c flag.

Hi @jeremy_k.

I combined the commands in a single line because I couldn't find another way to do it in qmake, it's automatically generated by the lines below, which can be seen in context by visiting this link from the SIMULinho.pro file

SOURCE_OBJVPI = simulinho_vpi.cpp
objvpi.name = Shared VPI Object Simulinho VPI
objvpi.input = SOURCE_OBJVPI
objvpi.dependency_type = TYPE_C
objvpi.depends = simulinho.o qrc_qml.o
#objvpi.variable_out = OBJECTS
objvpi.output = ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}.so
objvpi.clean = ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}.*
objvpi.commands = $${QMAKE_CXX} -c $(CXXFLAGS) -fPIC \
                                ${INCPATH} \
                                -fstack-protector-strong \
                                -Wformat -Werror=format-security -Wextra -Wshadow \
                                -fdebug-prefix-map=/build/iverilog-3pPO9t/iverilog-10.1=. \
                                -g \
                                -o ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}$${first(QMAKE_EXT_OBJ)} \
                                ${QMAKE_FILE_IN}
objvpi.commands += &&
objvpi.commands += $${QMAKE_CXX} --shared $(CXXFLAGS) \
                                 $(LIBS) \
                                 ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}$${first(QMAKE_EXT_OBJ)} qrc_qml.o \
                                 -o ${QMAKE_FILE_OUT} \
                                 simulinho.o
QMAKE_EXTRA_COMPILERS += objvpi

I tried to follow the same command model run by iVerilog's VPI module generator, which when compiled generates a file named iverilog-vpi.sh.

The generated .o file I use to compile the test which calls the GUI through the conventional main.cpp, and it works, the .vpi file if it doesn't have any reference to the one in Qt will also work, but if I do compiling using the above commands no longer works in vvp.

jeremy_k · wrote on 16 Aug 2021, 00:44

@Carlos-Delfino What did ldd report?

Carlos Delfino · 16 Aug 2021, 02:17

@jeremy_k said in My custom code with qt5 + qtquick2 in shared object:

ldd

ldd simulinho_vpi.vpi
	linux-gate.so.1 (0xb7f99000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7de3000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7dc5000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7be9000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7ae7000)
	/lib/ld-linux.so.2 (0xb7f9b000)

ldd simulinho_vpi.so
	linux-gate.so.1 (0xb7efb000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7d45000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7d27000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7b4b000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7a49000)
	/lib/ld-linux.so.2 (0xb7efd000)

simulinho_vpi.so and simulinho_vpi.vpi is the same file whitout debug information.

Strangely they are not referencing the QT libraries, in my understanding they should do it since I used the same parameters to generate them as for SIMULinho, differentiating in the addition of the --shared parameter.

Result for the executable is quite different:

 ldd SIMULinho 
	linux-gate.so.1 (0xb7f03000)
	libQt5Gui.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5 (0xb7919000)
	libQt5Qml.so.5 => /usr/lib/i386-linux-gnu/libQt5Qml.so.5 (0xb74a1000)
	libQt5Core.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 (0xb6f26000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6da0000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6d82000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6ba6000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6b86000)
	libGL.so.1 => /usr/lib/i386-linux-gnu/libGL.so.1 (0xb6b25000)
	libpng16.so.16 => /usr/lib/i386-linux-gnu/libpng16.so.16 (0xb6aeb000)
	libharfbuzz.so.0 => /usr/lib/i386-linux-gnu/libharfbuzz.so.0 (0xb6a42000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6a21000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb691f000)
	libQt5Network.so.5 => /usr/lib/i386-linux-gnu/libQt5Network.so.5 (0xb674d000)
	libicui18n.so.60 => /usr/lib/i386-linux-gnu/libicui18n.so.60 (0xb6484000)
	libicuuc.so.60 => /usr/lib/i386-linux-gnu/libicuuc.so.60 (0xb62c5000)
	libdouble-conversion.so.1 => /usr/lib/i386-linux-gnu/libdouble-conversion.so.1 (0xb62b0000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb62ab000)
	libglib-2.0.so.0 => /usr/lib/i386-linux-gnu/libglib-2.0.so.0 (0xb617a000)
	/lib/ld-linux.so.2 (0xb7f05000)
	libGLX.so.0 => /usr/lib/i386-linux-gnu/libGLX.so.0 (0xb6157000)
	libGLdispatch.so.0 => /usr/lib/i386-linux-gnu/libGLdispatch.so.0 (0xb60f8000)
	libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb6039000)
	libgraphite2.so.3 => /usr/lib/i386-linux-gnu/libgraphite2.so.3 (0xb600a000)
	libicudata.so.60 => /usr/lib/i386-linux-gnu/libicudata.so.60 (0xb4660000)
	libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb45e9000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb449f000)
	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb4473000)
	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb446e000)
	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb4467000)
	libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xb444c000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb4442000)

What should be done, say to paste these libraries into the shared file? or will I have to find a way to change vvp to make references to such libraries externally?

jeremy_k · wrote on 16 Aug 2021, 02:17

@Carlos-Delfino said in My custom code with qt5 + qtquick2 in shared object:

@jeremy_k said in My custom code with qt5 + qtquick2 in shared object:

ldd

ldd simulinho_vpi.vpi
	linux-gate.so.1 (0xb7f99000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7de3000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7dc5000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7be9000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7ae7000)
	/lib/ld-linux.so.2 (0xb7f9b000)

simulinho_vpi.so and simulinho_vpi.vpi is the same file whitout debug information.

Repeating the experiment with and without debugging information, or with different file names, is noise in the conversation at this point. Keep the focus of the question small. Extraneous issues can be resolved after the base case works.

Strangely they are not referencing the QT libraries, in my understanding they should do it since I used the same parameters to generate them as for SIMULinho, differentiating in the addition of the --shared parameter.

This suggests the program isn't really attempting to use any Qt functionality. Check that the source being built really is what it should be, clean, and build again.

What should be done, say to paste these libraries into the shared file? or will I have to find a way to change vvp to make references to such libraries externally?

Reference something in Qt that isn't inlined, and the linker should do the rest. Creating a QGuiApplication instance should do that.

Carlos Delfino · 16 Aug 2021, 04:31

@jeremy_k said in My custom code with qt5 + qtquick2 in shared object:

Reference something in Qt that isn't inlined, and the linker should do the rest. Creating a QGuiApplication instance should do that.

In the file simulinho_vpi.cpp, a function startMainWindow that is defined in this little one is called. relative to QT, for now it only has a very basic code.

This suggests the program isn't really attempting to use any Qt functionality. Check that the source being built really is what it should be, clean, and build again.

I've done it numerous times, I've already checked the generated files and their dates, to make sure they were fresh.

I removed the directory, and recreated it from scratch, unless there is a hidden cache I don't know about.

jeremy_k · 16 Aug 2021, 13:11

@Carlos-Delfino Does nm --undefined-only <library name> list missing Qt symbols? It should produce output with U next to each symbol referenced but not defined in the file.

$ nm --undefined-only missing.so 
                 w __cxa_finalize@@GLIBC_2.2.5
                                  w __gmon_start__
                                  w _ITM_deregisterTMCloneTable
                                  w _ITM_registerTMCloneTable
                                  U sqrt@@GLIBC_2.2.5
                                  U _Z1fv

Carlos Delfino · wrote on 16 Aug 2021, 05:25

I found a small error on my part in the code, I had commented out an important line to test, "after" this error arose.

Anyway, I found another way to generate the vpi object, which led me to identify another problem, an important variable for vpi (vlog_startup_routine) is disappearing too.

Allow me a few hours (due to the time difference) to rest, and retest the code.

With this new approach the errors have changed, and it seems to have resolved the previous one.

Carlos Delfino · 17 Aug 2021, 00:19

@jeremy_k said in My custom code with qt5 + qtquick2 in shared object:

Does nm --undefined-only <library name> list missing Qt symbols? It should produce output with U next to each symbol referenced but not defined in the file.

Good morning @jeremy_k .

Resuming the studies, I am now using only the code that generated the initial problem, the result of the nm command follows:

 nm --undefined-only simulinho_vpi.vpi
         U __cxa_atexit@@GLIBC_2.1.3
         w __cxa_finalize@@GLIBC_2.1.3
         w __gmon_start__
         U __gxx_personality_v0@@CXXABI_1.3
         w _ITM_deregisterTMCloneTable
         w _ITM_registerTMCloneTable
         U printf@@GLIBC_2.0
         U __stack_chk_fail@@GLIBC_2.4
         U _Unwind_Resume@@GCC_3.0
         U vpi_printf
         U vpi_register_systf
         U _Z21qRegisterResourceDataiPKhS0_S0_
         U _Z23qUnregisterResourceDataiPKhS0_S0_
         U _Z9qt_assertPKcS0_i
         U _ZN10QArrayData10deallocateEPS_jj
         U _ZN15QGuiApplication4execEv
         U _ZN15QGuiApplicationC1ERiPPci
         U _ZN15QGuiApplicationD1Ev
         U _ZN16QCoreApplication12setAttributeEN2Qt20ApplicationAttributeEb
         U _ZN21QQmlApplicationEngine11rootObjectsEv
         U _ZN21QQmlApplicationEngine4loadERK4QUrl
         U _ZN21QQmlApplicationEngineC1EP7QObject
         U _ZN21QQmlApplicationEngineD1Ev
         U _ZN4QUrlC1ERK7QStringNS_11ParsingModeE
         U _ZN4QUrlD1Ev
         U _ZN9QListData7disposeEPNS_4DataE

Carlos Delfino · wrote on 16 Aug 2021, 15:24

@Carlos-Delfino said in My custom code with qt5 + qtquick2 in shared object:

disappearing

What differs the executable (represented by the SIMULinho file), running without problems, from the shared object (represented by simulinho_vpi.so or simulinho_vpi.vpi), with problem, is that the executable has the main.o object that defines the main() input function.

In theory, the shared object simulinho_vpi.vpi should have everything to perform the VPI calls (orchestrated by iVerilog's VPP) and Qt5. I tried to do a final link the same way the executable is generated, but in this process the only variable defined as extern (vlog_startup_routines), is through it that the VPP learns about the entry points.

From what I researched I have two alternatives:

Find a way to tell the VPP where to find the missing libraries, which seems unfeasible for the moment, as I would have to change the original iVerilog code.
Ensure static presence of all necessary libraries that are not recognized by the VPP. (current method not working)

jeremy_k · wrote on 17 Aug 2021, 00:19

@Carlos-Delfino said in My custom code with qt5 + qtquick2 in shared object:

Resuming the studies, I am now using only the code that generated the initial problem, the result of the nm command follows:
 nm --undefined-only simulinho_vpi.vpi
         U _Z21qRegisterResourceDataiPKhS0_S0_

This means that the library is attempting to reference symbols that should be in libQt5Core. Does ldd report that link?

If not, then something is going wrong at the linking stage.
If it does but reports that the library can't be found, then the dynamic linker will need some additional help at runtime.

Carlos Delfino · wrote on 17 Aug 2021, 01:25

Based on the suggestion of one of the collaborators of the iVerilog project, I managed to compile an example externally to QtCreator that interacts as I wish with Qt5. The link is here.

Now I'm going to try tweaking this method so it interacts with QtCreator and qmake.

What's bothering me is the need to manually inform the directories more explicitly about the Qt5 libraries. Below is the example command used in iVerilog:

$ iverilog-vpi -I/usr/lib/i386-linux/gnu \
                     -I/usr/include/i386-linux-gnu/qt5/QtGui \
                     -I/usr/include/i386-linux-gnu/qt5/QtWidgets \
                     -I/usr/include/i386-linux-gnu/qt5/ \
                     -lQt5Widgets -lQt5Core qtapp.cc
Compiling qtapp.cc...

Carlos Delfino · wrote on 17 Aug 2021, 01:53

S U C C E S S

The order of parameters was affecting the linkage:

 make verilognize
/usr/lib/qt5/bin/qmake -o Makefile ../SIMULinho.old/SIMULinho.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug
rm -f simulinho_vpi.o simulinho_vpi.so
rm -f simulinho_vpi.vpi simulinho_vpi.vpi.debug
g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_VERSION_TAGGING -DSIMULINHO_SHAREDLIB -D__SIMULINHO_DUMP__ -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -fPIC -I../SIMULinho.old -I. -I/usr/local/lib/ivl/include -isystem /usr/local/include/iverilog -isystem /usr/include/i386-linux-gnu/qt5 -isystem /usr/include/i386-linux-gnu/qt5/QtQuick -isystem /usr/include/i386-linux-gnu/qt5/QtGui -isystem /usr/include/i386-linux-gnu/qt5/QtQml -isystem /usr/include/i386-linux-gnu/qt5/QtNetwork -isystem /usr/include/i386-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I/usr/lib/i386-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/i386-linux-gnu/qt5/QtGui -I/usr/include/i386-linux-gnu/qt5/QtWidgets -fstack-protector-strong -Wformat -Werror=format-security -Wextra -Wshadow -fdebug-prefix-map=/build/iverilog-3pPO9t/iverilog-10.1=. -g -o simulinho_vpi.o ../SIMULinho.old/simulinho_vpi.cpp && g++ -o simulinho_vpi.so --shared -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_VERSION_TAGGING -DSIMULINHO_SHAREDLIB -D__SIMULINHO_DUMP__ -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB simulinho_vpi.o qrc_qml.o simulinho.o  -L/usr/lib/i386-linux-gnu -L/usr/local/lib/ -lvpi -lveriuser -lQt5Quick -lQt5Gui -lQt5Qml -lQt5Network -lQt5Core -lGL -lpthread 
../SIMULinho.old/simulinho_vpi.cpp: In function ‘int simulinho_ui_compiletf(char*)’:
../SIMULinho.old/simulinho_vpi.cpp:13:40: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int simulinho_ui_compiletf(char*user_data){
                                        ^~~~~~~~~
../SIMULinho.old/simulinho_vpi.cpp: In function ‘int simulinho_ui_calltf(char*)’:
../SIMULinho.old/simulinho_vpi.cpp:17:37: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int simulinho_ui_calltf(char*user_data){
                                     ^~~~~~~~~
../SIMULinho.old/simulinho_vpi.cpp: In function ‘int hello_compiletf(char*)’:
../SIMULinho.old/simulinho_vpi.cpp:27:33: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int hello_compiletf(char*user_data)
                                 ^~~~~~~~~
../SIMULinho.old/simulinho_vpi.cpp: In function ‘int hello_calltf(char*)’:
../SIMULinho.old/simulinho_vpi.cpp:32:30: warning: unused parameter ‘user_data’ [-Wunused-parameter]
 static int hello_calltf(char*user_data)
                              ^~~~~~~~~
cp --remove-destination simulinho_vpi.so simulinho_vpi.vpi
iverilog -L .  -m simulinho_vpi -o simulinho.vvp /home/carlosdelfino/workspace/RISCuinho/SIMULinho.old/simulinho.v && vvp -v simulinho.vvp
Hell Register!Simulinho UI Open Register!Simulinho UI Close Register!Compiling VVP ...
 ... VVP file version 11.0 (stable) (v11_0-72-gd3b0992a)
Hell Register!Simulinho UI Open Register!Simulinho UI Close Register!Compile cleanup...
 ... Linking
 ... Removing symbol tables
 ... Compiletf functions
 ...        0 functors (net_fun pool=524288 bytes)
                  0 logic
                  0 bufif
                  0 resolv
                  0 signals
 ...        0 filters (net_fil pool=524288 bytes)
 ...        7 opcodes (16384 bytes)
 ...        0 nets
 ...        0 vvp_nets (0 bytes)
 ...        0 arrays (0 words)
 ...        0 memories
                  0 logic (0 words)
                  0 real (0 words)
 ...        1 scopes
 ... 0.015737 seconds, 67996.0/11308.0/9656.0 KBytes size/rss/shared
Running ...
 ...execute EndOfCompile callbacks
 ...propagate initialization events
 ...execute StartOfSim callbacks
 ...run scheduler
Hello, World!
Executando com Argumentos: SIMULINHO VPIExecutando com Argumentos: SIMULINHO VPI ...execute Postsim callbacks
 ... 0,706909 seconds, 150316,0/45488,0/32884,0 KBytes size/rss/shared
Event counts:
           4 time steps (pool=204)
           4 thread schedule events
           0 assign events
             ...assign(vec4) pool=16384
             ...assign(vec8) pool=409
             ...assign(real) pool=409
             ...assign(word) pool=256
             ...assign(word/r) pool=341
           0 other events (pool=8192)
echo V E R I L O G N I Z E
V E R I L O G N I Z E

Carlos Delfino · wrote on 17 Aug 2021, 02:05

@jeremy_k Obrigado pela ajuda! (Thank you for your help!)