-
Notifications
You must be signed in to change notification settings - Fork 26
Simulating with GHDL on Windows produces a segmentation fault #62
Comments
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. |
@edbordin, what whould be the minimal set of commands for executing https://github.com/umarcor/fpga-toolchain/blob/ghdl/win-sim/.github/workflows/ghdl.yml |
@umarcor Today I got around to adding some more up-to-date dev instructions in |
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...
|
I tried this approach:
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:
|
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:
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 |
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.
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:
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 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. |
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. |
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:
These |
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 |
In fact, I tried with and without |
I got a little step forward. I changed EDIT |
Refs:
|
The text was updated successfully, but these errors were encountered: