Simulating with GHDL on Windows produces a segmentation fault

[umarcor]

library ieee;
context ieee.ieee_std_context;

entity tb is
end;

architecture arch of tb is

begin

  process
  begin
    report "Start simulation" severity note;
    report "End simulation" severity failure;
  end process;

end;

export FPGA_TOOLCHAIN=/t/fomu/fomu-toolchain-Windows
PATH=$FPGA_TOOLCHAIN/bin:$PATH ghdl -a --std=08 sim_fault.vhd
PATH=$FPGA_TOOLCHAIN/bin:$PATH ghdl -r --std=08 tb
Segmentation fault

[edbordin]

Hmm, that does seem to work with the linux build, unsure what the problem is. I only ever checked basic synthesis worked though so it's unsurprising not all of it works.

If you want to investigate with mingw gdb, there are debug symbols in the build artifacts which I avoided pushing to the github releases to reduce the clutter. https://dev.azure.com/open-tool-forge/fpga-toolchain/_build/results?buildId=459&view=artifacts&type=publishedArtifacts

I can't work out how to make the artifacts downloadable by anonymous users but I'm happy to provide contributor access if you need it.

If there is a fix we should add a basic ghdl sim test script to make sure it continues working.

[umarcor]

@edbordin, what whould be the minimal set of commands for executing ./scripts/compile_ghdl.sh?

https://github.com/umarcor/fpga-toolchain/blob/ghdl/win-sim/.github/workflows/ghdl.yml

[edbordin]

@umarcor Today I got around to adding some more up-to-date dev instructions in DEVELOPMENT.md. It's intended to run via build.sh. In this case you would want to disable almost everything except for INSTALL_DEPS, COMPILE_GHDL (and maybe COMPILE_YOSYS if you need to check anything in ghdl-yosys-plugin). Now that I think of it, stripping debug symbols is implemented as a bash function, so it would make sense to add another flag that makes that function a no-op for situations like this.

[umarcor]

After fighting with it for a while (https://github.com/umarcor/fpga-toolchain/runs/1286948521?check_suite_focus=true#step:5:1086), I realised that... mcode is NOT supported on Windows 64 bit. It is supported on GNU/Linux 32 or 64, and on Windows 32, but NOT Windows 64. Hence, no matter how hard I try, it won't work. We have three options:

• Use mingw-w64-i686-* packages and build GHDL with mcode backend on MINGW32.
• Build with LLVM backend on MINGW64.
• Document that the GHDL provided in this toolchain is for synthesis only. That is, both ghdl-yosys-plugin and ghdl --synth do work (so keeping the GHDL executable is useful), but no simulation is possible.

[umarcor]

• Use mingw-w64-i686-* packages and build GHDL with mcode backend on MINGW32.

I tried this approach:

• umarcor@39e33a9
• https://github.com/umarcor/fpga-toolchain/runs/1289066447?check_suite_focus=true#step:5:1091

Build is successful, but the check fails because the result is not exactly static. I guess that's because it's a 32 bit binary to be used on a 64 bit environment:

 - 2. File is executable
	ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x7ffd1a820000)
	ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x76ee0000)
	wow64.dll => /c/windows/System32/wow64.dll (0x7ffd18d40000)
	wow64win.dll => /c/windows/System32/wow64win.dll (0x7ffd186b0000)

[edbordin]

I realised that... mcode is NOT supported on Windows 64 bit. It is supported on GNU/Linux 32 or 64, and on Windows 32, but NOT Windows 64.

Hmm, this issue is few years old but someone claimed to have it working on 64-bit mingw here. But you know your way around GHDL so I'll take your word for it.

There actually used to be 32-bit targets for some tools in these scripts and I removed them to reduce maintenance burden. I was thinking I would get away with it in this day and age but I guess the solution might be to add a 32-bit windows package.

Off the top of my head, the tasks involved:

1. Convert the windows CI build to a matrix config that does 64-bit and 32-bit mingw.
2. Add a 32-bit windows environment to run the test scripts in. I think it's also worth checking the 32-bit tools work on a 64-bit host to catch any quirks.
3. Fix that static binary test script *
4. Make sure ABC_ARCHFLAGS is set correctly for 32-bit (or alternatively see if we can run a configure script instead to make this easier to maintain)
5. Document the limitations of ghdl on 64-bit windows.

I'm happy to assist, particularly with the azure pipelines config since I didn't document anything to do with that.

* The static check on windows is pretty ad-hoc. In hindsight, probably a better way I could have done it is use a pattern along the lines of /\w+/[Ww][Ii][Nn][Dd][Oo][Ww][Ss]/.*\.[Dd][Ll][Ll] to cover the system dlls rather than listing them out so specifically.

[umarcor]

I think that Patrick made the necessary modifications for achieving the currently supported environments (MINGW32-mcode, MINGW32-llvm and MINGW64-llvm), and he also got to build MINGW64-mcode (that's why this repo works ATM). But MINGW64-mcode simulation did never work. Anyway, let's ping him for confirmation: @Paebbels.

There actually used to be 32-bit targets for some tools in these scripts and I removed them to reduce maintenance burden. I was thinking I would get away with it in this day and age but I guess the solution might be to add a 32-bit windows package.

Honestly, I would not try providing 32 bit targets with mcode. Instead, I would provide 64 bit targets with LLVM. This is because mcode is an in-memory backend, which generates machine code directly:

• Co-simulation features are limited to pre-built shared libraries. Conversely, LLVM allows building VHDL sources along with foreign C code. See https://ghdl.github.io/ghdl-cosim/vhpidirect/index.html.
• Some users rely on *.o files generated/updated after analysis for setting up their Makefiles.
• mcode is for x86 only, not for ARM or other architectures. However, either LLVM or GCC allows building GHDL on armv7, armv8, ppc64, etc.

My concern is whether we can generate a static build of GHDL with LLVM backend on MINGW64. That's what I wanted to try next.

I'm happy to assist, particularly with the azure pipelines config since I didn't document anything to do with that.

I think the important part is to guess the set of flags/options we need. Adapting scripts from Azure to/from GitHub Actions and/or Travis is trivial.

EDIT

For example, in https://github.com/dbhi/vboard/tree/main/vga I use this toolchain for synthesis, but https://github.com/ghdl/ghdl/releases/download/nightly/mingw-w64-x86_64-ghdl-llvm-ci-1-any.pkg.tar.zst for co-simulation.

[edbordin]

OK, if we can make it all work on 64-bit that sounds ideal. As you point out, the thing to work out is whether LLVM can be statically linked. I'm also interested how large it is and whether it relies on any global install prefixes to work correctly.

[umarcor]

Work in progress: https://github.com/umarcor/fpga-toolchain/commits/ghdl/llvm

    ./configure --prefix=$PACKAGE_DIR/$NAME --with-llvm-config="llvm-config --link-static --libfiles" LDFLAGS="-static" --enable-libghdl --enable-synth --default-pic
    $MAKE -j$J GNAT_BARGS="-bargs -E -static" GNAT_LARGS="-static"
    $MAKE install

Successful build, but failing execution:

...
  sanity 000hello: failed
  analyze hello.vhdl
  elaborate and simulate hello
  D:/a/_temp/msys/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\fpga-toolchain\fpga-toolchain\_packages\build_windows_amd64\fpga-toolchain\lib/ghdl/libgrt.a(grt-vcdz.o): in function `grt__vcdz__my_vcd_put':
  D:/a/fpga-toolchain/fpga-toolchain/_builds/build_windows_amd64/ghdl/src/grt/grt-vcdz.adb:43: undefined reference to `gzwrite'
  D:/a/_temp/msys/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\fpga-toolchain\fpga-toolchain\_packages\build_windows_amd64\fpga-toolchain\lib/ghdl/libgrt.a(grt-vcdz.o): in function `grt__vcdz__my_vcd_putc':
...

These linker input file unused because linking not done messages are suspicious: https://github.com/umarcor/fpga-toolchain/runs/1291286777?check_suite_focus=true#step:5:322

[edbordin]

I remember being confused trying to work out the right set of flags to get a static link. Looks like the linker flags for llvm aren't ending up in the right place and also seems like you've removed the link with zlib (which causes the error about gzwrite). Maybe try adding GNAT_LARGS="-static -lz $(llvm-config --link-static --libfiles)" to what you already have.

[umarcor]

In fact, I tried with and without -lz, and I got the same result. Now I tried with the flags you suggested (umarcor@8ef4c31), and it's still producing the same result: https://github.com/umarcor/fpga-toolchain/runs/1295596412?check_suite_focus=true#step:5:1453. I asked Tristan for some hint.

[umarcor]

I got a little step forward. I changed CC and CXX for using clang (which I forgot before). At the same time, I changed HOST_FLAGS to --host=x86_64-w64-mingw64. Now I think I'm getting a legit error: https://github.com/umarcor/fpga-toolchain/runs/1295796828?check_suite_focus=true#step:5:683. That is, src/grt/config/jumps.c might need to be tweaked.

EDIT

msys2/MINGW-packages#5757 (comment)

[umarcor]

Refs:

• GHDL was upstreamed to MSYS2: ghdl: add split package msys2/MINGW-packages#6688
• There is a PR for fixing the test issue when using clang++ for LLVM backend on Windows: win32: add fprintf to grt_save_backtrace ghdl/ghdl#1516.