Re: [Iverilog-devel] Why use SFT files?

[Martin W. <ic...@ma...>]

I'm already reusing the vvp/ivl_dlfcn.h header. Dynamically loading the 
modules is not the problem; allowing the modules to call back to the VPI 
routines implemented in the main program (e.g. vpi_register_systf) is.

In Linux (and I guess in MacOS), those routines are left as undefined 
references in the VPI module:

% objdump -t v2005_math.vpi | grep vpi_register_systf
0000000000000000         *UND*	0000000000000000              vpi_register_systf

When the module is dynamically loaded, these references get resolved by 
name, using whatever is provided by the loading program (or other libraries 
it has dynamically loaded). So any program can load and use the module, 
providing it implements the necessary functions.

In Windows, the VPI modules are linked to vvp/libvpi.a, which is created by 
dlltool from vvp.exe. This contains the relocation information for all the 
symbols exported by vvp, and that information gets hardwired into the VPI 
modules. So if a VPI module is dynamically loaded by a different program, 
the addresses are all wrong, calls to the VPI routines jump to some random 
place in the loading program, and chaos ensues.

I searched for a way to make Windows resolve references at load time, but 
couldn't find anything, hence I did it manually.

If you don't like the use of macros to translate the calls, we could 
provide wrapper functions in the new libvpi. It would be a little less 
efficient, but most likely insignificant in the overall cost of making VPI 
calls.

Stephen Williams wrote:
> VPI modules can be dynamically loaded by vvp in Windows and Mac, so
> shouldn't that same functionality work with ivl on Windows? The
> vvp/ivl_dlfcn.h header file encapsulates this. Perhaps that header can
> be moved to libmisc.
> 
> On Wed, Oct 23, 2019 at 8:18 AM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> This was triggered by my writing a regression test for the recently
>> reported bug, and finding that vpi_reg.pl didn't really support tests with
>> SFT files...
>>
>> I've implemented the compiler change to read VPI modules directly in the
>> sft-rework branch. Apart from exposing another issue in the vlog95 target,
>> all the existing tests still pass.
>>
>> Implementing this for Linux was pretty easy. Fixing the problems in Windows
>> took a bit longer. As far as I can tell, there's no way for a DLL to
>> automatically link to functions provided by the client application. The
>> existing approach of linking the VPI module to vvp meant it couldn't then
>> be used by the compiler. I solved that by passing a jump table down to the
>> VPI module when it was loaded.
>>
>> See what you think. There's a sft_rework branch in the test suite which
>> makes vpi_reg.pl use the new functionality.
>>
>> Stephen Williams wrote:
>>> Because the .sft has some specificity that the .vpi does not have?
>>> Also, to read the .vpi file, you need to dynamically link it in so
>>> that you can read the tables. The ivl program currently does not need
>>> to load .vpi files, it can use the .sft files instead.
>>>
>>> That may be obsolete thinking, though...
>>>
>>> On Sun, Oct 20, 2019 at 12:19 PM Martin Whitaker
>>> <ic...@ma...> wrote:
>>>>
>>>> It is easy enough to extract the information from the .vpi file. I've
>>>> written a small standalone utility that does just that and writes out a
>>>> .sft file. But why not get the compiler to do it on the fly, rather than go
>>>> though an intermediate step?
>>>>
>>>>
>>>> _______________________________________________
>>>> Iverilog-devel mailing list
>>>> Ive...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
>