$display() causes a segmentation fault when invoked on windows

[bertgoz]

Using openVAF 23_2_0 and Windows MSVC (with Desktop development C++ package) I obtain the following compilation error when using the $display function:

error LNK2019: unresolved external symbol snprintf referenced in function cb.2

[dwarning]

It is similar to closed issue #35. Please try the nightly build from Readme in front.

[bertgoz]

Thanks, it now compiles but the nightly release is not compatible with ngspice-39

[dwarning]

Why?

Am 14.02.23 um 19:43 schrieb bertgoz:

Thanks, it now compiles but the nightly release is not compatible with ngspice-39

— Reply to this email directly, view it on GitHub https://github.com/pascalkuthe/OpenVAF/issues/39#issuecomment-1430210241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMWNTAQVMGKJ3XBDWYAUR3WXPG33ANCNFSM6AAAAAAU3XEGTY. You are receiving this because you commented.Message ID: @.***>

[bertgoz]

I get "internal error -- segmentation violation" when running a circuit containing the compiled module with $display() in ngspice-39 Windows.

Without $display() the circuit runs fine (both in the openVAF official release and the nightly)

[pascalkuthe]

Thank your for reporting this bug. The same problem was already reported on the ngspice user forum.

The segmentation fault is windows specific and seems to be a problem with the way the C standard library works on windows. Sadly linking to the standard library (as a compiler) is a lot more challenging on windows (whereas the something is almost trivial on macos/linux).

I am actively working on the problem but its a bit challenging to solve.

[EternalXY]

It looks like this crashes because osdi_log is not exported under Windows, and ngspice does not check that the symbol exists when importing it. At least it works for me when this symbol is exported:

diff --git a/openvaf/osdi/src/lib.rs b/openvaf/osdi/src/lib.rs
index 6268822..1af54b0 100644
--- a/openvaf/osdi/src/lib.rs
+++ b/openvaf/osdi/src/lib.rs
@@ -209,6 +209,9 @@ pub fn compile(
         let val = cx.const_null_ptr(cx.ptr_ty(fun_ty));
         unsafe {
             llvm::LLVMSetInitializer(osdi_log, val);
+            llvm::LLVMSetLinkage(osdi_log, llvm::Linkage::ExternalLinkage);
+            llvm::LLVMSetUnnamedAddress(osdi_log, llvm::UnnamedAddr::No);
+            llvm::LLVMSetDLLStorageClass(osdi_log, llvm::DLLStorageClass::Export);
         }

         debug_assert!(llmod.verify_and_print());

[pascalkuthe]

thank you so much for digging into this. This does indeed seem to fix the problem. I was totally going in the wrong direction by looking at the standard library. There is simply so much complexity involved with targeting windows compared to other platforms that I missed the obvious. The fact that getting any kind of debugging setup on windows in VM super cumbersome made this a pain to debug and I just put it off

[EternalXY]

:thumbsup: