Allow building GHDL mcode on FreeBSD #1020

endofexclusive · 2019-11-14T20:23:43Z

These commits enables building of GHDL (mcode) on FreeBSD 12.1. Each of the three commits fixes one individual build failure. This pull request also fixes #501.

The exact configure and build commands for the successful build is:

MAKE=gmake ../configure CC=cc GNATMAKE=/usr/local/gcc6-aux/bin/gnatmake --prefix=/opt/ghdl-mcode
gmake

System information:

$ uname -a
FreeBSD cl 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
$ cc -v
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

Not available on FreeBSD 12 for example

On FreeBSD 12.1, this commit fixes: gnatlink ghdl_jit.ali -o ghdl_mcode -g memsegs_c.o chkstk.o jumps.o times.o grt-cbinding.o grt-cvpi.o grt-cdynload.o fstapi.o lz4.o fastlz.o -lm -Wl,--version-script=/home/asdf/repos/ghdl/build/../src/grt/grt.ver -Wl,--export-dynamic /usr/local/bin/ld: ghdl_mcode: local symbol `__progname' in /usr/lib/crt1.o is referenced by DSO /usr/local/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status gnatlink: error when calling /usr/local/gcc6-aux/bin/ada gnatmake: *** link failed. gmake: *** [Makefile:183: ghdl_mcode] Error 4

eine · 2019-11-14T20:32:42Z

@endofexclusive, according to #501, you previously tried to use LLVM backend. Is this fix specific to mcode because LLVM is working already? Or you did not try LLVM recently?

Furthermore, did you try to execute GHDL=ghdl ./testsuite.sh after building/installing GHDL? That's not a stopper to merge this PR. However, since we don't have any FreeBSD CI job, it'd be good to know what other users can expect.

endofexclusive · 2019-11-14T21:57:28Z

I have now investigated how GHDL built with LLVM and mcode backends work in more detail using the testsuite.

Executive summary after exploring the testsuite

Details are given below.

`ghdl_llvm` on master

ghdl_llvm built on master crashes when analyzing some files.
ghdl_llvm built on master fails on elaboration due to unresolved symbol reference to environ.
ghdl_llvm built on master fails on first test in testsuite, due to unresolved symbol.

`ghdl_llvm` on pr/mcode-on-freebsd12

ghdl_llvm built on pr/mcode-on-freebsd12 crashes when analyzing some files.
ghdl_llvm built on pr/mcode-on-freebsd12 can elaborate.
ghdl_llvm built on pr/mcode-on-freebsd12 fails on fourth test in testsuite, due to crash.

`ghdl_mcode` on master

ghdl_mcode does not build at all on master. (primary focus of the pull request)

`ghdl_mcode` on pr/mcode-on-freebsd12

ghdl_mcode built on pr/mcode-on-freebsd12 fails on the 113th test (gna bug16782) in testsuite, due to crash.

I understand that FreeBSD support may not be of high priority for GHDL. However, the observed behavior could be of interest if it can reveal issues which are latent also on other systems.

Details

On master building with LLVM backend

$ mkdir build-llvm-master && cd build-llvm-master
$ MAKE=gmake ../configure CC=cc GNATMAKE=/usr/local/gcc6-aux/bin/gnatmake --with-llvm-config=/usr/local/llvm80/bin/llvm-config --prefix=/opt/ghdl-llvm
$ PATH=/usr/local/gcc6-aux/bin:$PATH gmake

A ghdl_llvm binary is created successfully by the make command line. However, the build (gmake) fails when analyzing VHDL files. It looks like this:

cd lib/ghdl/ieee/v87; \
for i in ieee/v87/std_logic_1164.vhdl ieee/v87/std_logic_1164-body.vhdl ieee/v87/numeric_bit.vhdl ieee/v87/numeric_bit-body.vhdl ieee/v87/numeric_std.vhdl ieee/v87/numeric_std-body.vhdl openieee/upf.vhdl openieee/upf-body.vhdl vital95/vital_timing.vhdl vital95/vital_timing-body.vhdl vital95/vital_primitives.vhdl vital95/vital_primitives-body.vhdl; do \
          cmd="/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm -a --GHDL1=/home/asdf/repos/ghdl/build-llvm-master/ghdl1-llvm  --std=87 -P../.. --work=ieee ../../src/$i";\
  echo $cmd; eval $cmd || exit 1; \
done
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm -a --GHDL1=/home/asdf/repos/ghdl/build-llvm-master/ghdl1-llvm --std=87 -P../.. --work=ieee ../../src/ieee/v87/std_logic_1164.vhdl
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm -a --GHDL1=/home/asdf/repos/ghdl/build-llvm-master/ghdl1-llvm --std=87 -P../.. --work=ieee ../../src/ieee/v87/std_logic_1164-body.vhdl
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm -a --GHDL1=/home/asdf/repos/ghdl/build-llvm-master/ghdl1-llvm --std=87 -P../.. --work=ieee ../../src/ieee/v87/numeric_bit.vhdl
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm -a --GHDL1=/home/asdf/repos/ghdl/build-llvm-master/ghdl1-llvm --std=87 -P../.. --work=ieee ../../src/ieee/v87/numeric_bit-body.vhdl

Execution terminated by unhandled exception
raised STORAGE_ERROR : stack overflow or erroneous memory access
Call stack traceback locations:
0x80491b3cc 0x80491a98d
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm:error: compilation error
gmake[1]: *** [../libraries/Makefile.inc:182: lib/ghdl/ieee/v87/ieee-obj87.cf] Error 1
gmake[1]: Leaving directory '/home/asdf/repos/ghdl/build-llvm-master'
gmake: *** [Makefile:323: libs.vhdl.llvm] Error 2

Re-running the exact same make command gives the same error, but seemingly for different VHDL libraries. After a couple of times make eventually succeeds. I assume it is because the
make dependencies gets resolved although with corrupted output files.

Then using this ghdl_llvm to run the testsuite, I get:

$ git describe --tags --dirty
v0.36-1225-gc4443c4e-dirty
$ git diff
diff --git a/testsuite/testsuite.sh b/testsuite/testsuite.sh
index 797e733e..bd23abfe 100755
--- a/testsuite/testsuite.sh
+++ b/testsuite/testsuite.sh
@@ -1,4 +1,4 @@
-#! /bin/bash
+#!/usr/bin/env bash

$ cd testsuite
$ PATH=/usr/local/gcc6-aux/bin:$PATH GHDL=`realpath ../build-llvm-master/ghdl_llvm` ./testsuite.sh
INFO: not in CI
tests: sanity gna vests synth
[GHDL - test] sanity
sanity 000hello: failed
analyze hello.vhdl
elaborate and simulate hello
/usr/local/bin/ld: hello: local symbol `environ' in /usr/lib/crt1.o is referenced by DSO
/usr/local/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
/home/asdf/repos/ghdl/build-llvm-master/ghdl_llvm: compilation error

On pr/mcode-on-freebsd12 building with LLVM backend

$ mkdir build-llvm-pr-mcode-on-freebsd12 && cd build-llvm-pr-mcode-on-freebsd12
$ MAKE=gmake ../configure CC=cc GNATMAKE=/usr/local/gcc6-aux/bin/gnatmake --with-llvm-config=/usr/local/llvm80/bin/llvm-config --prefix=/opt/ghdl-llvm
$ PATH=/usr/local/gcc6-aux/bin:$PATH gmake

Same behavior is seen as on master for the crashing ghdl_llvm. And again make succeeds after a number of tries.

Using this ghdl_llvm to run the testsuite,

$ git describe --tags --dirty
v0.36-1228-ge55c3055-dirty
$ git diff
diff --git a/testsuite/testsuite.sh b/testsuite/testsuite.sh
index 797e733e..bd23abfe 100755
--- a/testsuite/testsuite.sh
+++ b/testsuite/testsuite.sh
@@ -1,4 +1,4 @@
-#! /bin/bash
+#!/usr/bin/env bash

$ PATH=/usr/local/gcc6-aux/bin:$PATH GHDL=`realpath ../build-llvm-pr-mcode-on-freebsd12/ghdl_llvm` ./testsuite.sh
INFO: not in CI
tests: sanity gna vests synth
[GHDL - test] sanity
sanity 000hello: ok
sanity 001hello87: ok
sanity 002hello2008: ok
sanity 004all08: failed
analyze all08.vhdl

Execution terminated by unhandled exception
raised STORAGE_ERROR : stack overflow or erroneous memory access
Call stack traceback locations:
0x80491b3cc 0x80491a98d
/home/asdf/repos/ghdl/build-llvm-pr-mcode-on-freebsd12/ghdl_llvm: compilation error

Observation

The pull request (GRT_EXTRA_LIB) indeed gets rid of link errors for LLVM, but there are
still run time errors.

Testsuite on ghdl_mcode

The testsuite is more successful using mcode on pr/mcode-on-freebsd12. However, there is crash after 113 tests.

$ cd testsuites
$ PATH=/usr/local/gcc6-aux/bin:$PATH GHDL=`realpath ../build/ghdl_mcode` ./testsuite.sh
[...]
gna bug16695: ok
gna bug16782: failed
analyze bug.vhd
elaborate and simulate (failure expected) bug

Execution terminated by unhandled exception
raised CONSTRAINT_ERROR : SIGFPE
Call stack traceback locations:
0x800b063cc 0x800b0598d 0x7ffffffff001 0x8016989cf

The exact command line is:

$ cd gna/bug16782
$ ../../../build/ghdl_mcode --elab-run bug --expect-failure

Execution terminated by unhandled exception
raised CONSTRAINT_ERROR : SIGFPE
Call stack traceback locations:
0x800b063cc 0x800b0598d 0x7ffffffff001 0x8016989cf

eine · 2019-11-14T22:53:23Z

I have now investigated how GHDL built with LLVM and mcode backends work in more detail using the testsuite.

Thanks a lot! That's very helpful.

I understand that FreeBSD support may not be of high priority for GHDL. However, the observed behavior could be of interest if it can reveal issues which are latent also on other systems.

Actually, GHDL is not biased at all; there is no explicit priority regarding OS or architectures. I believe that @tgingold uses Debian on amd64, so that's where everything is first tested. Then, it is up to the users to test it on different platforms and help debug/fix issues locally. The same applies to the backends: Tristan normally works on mcode first, and LLVM/GCC bugs are found slightly later.

However, it is true that FreeBSD is not explicitly listed as a supported platform in the README. I believe this is because we don't have a CI service for it, so we cannot guarantee/test that it works.

It seems that running FreeBSD on Travis CI is quite complex (http://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html). I have not found any reference about running FreeBSD on GitHub Actions, but I expect it to be equally complex (unless nested virtualization is supported). Fortunately, Cirrus CI provides FreeBSD VMs (https://cirrus-ci.org/guide/FreeBSD/) and it's free (as in free beer) for open source projects (https://cirrus-ci.org/pricing/). We might consider adding Cirrus CI for FreeBSD only. However, I think we need to first investigate how to allow failures, to avoid every commit failing until support is fixed. @tgingold, wdyt?

tgingold · 2019-11-15T05:47:50Z

configure

@@ -368,7 +368,7 @@ fi
 # Generate ortho_code-x86-flags
 if test $backend = mcode; then
  case "$build" in
-    *darwin*) ortho_flags="Flags_Macosx${mcode64}" ;;
+    *darwin* | *freebsd* ) ortho_flags="Flags_Macosx${mcode64}" ;;


Is there any reason to use Flags_Macosx instead of Flags_Linux ?
The difference is the stack alignment on x86. For darwin it is 16 bytes, for linux it is 8 bytes.
I thought that Freebsd is closer to linux.

tgingold · 2019-11-15T05:48:57Z

src/grt/Makefile.inc

@@ -56,7 +56,7 @@ else
    GRT_EXTRA_LIB=-ldl -lm $(GRT_ELF_OPTS)
  endif
  ifeq ($(filter-out netbsd freebsd% dragonfly%,$(osys)),)
-    GRT_EXTRA_LIB=-lm $(GRT_ELF_OPTS)
+    GRT_EXTRA_LIB=-lm


If you get ride of GRT_ELF_OPTS, you might have issues with VPI.
I am ok with that change, but it must affect only freebsd.

tgingold · 2019-11-15T05:52:38Z

src/ortho/mcode/memsegs_c.c

@@ -28,7 +28,7 @@
   set rights.
 */

-#ifdef __APPLE__
+#if defined(__APPLE__) || !defined(MREMAP_MAYMOVE)


If freebsd supports mremap(2), better to use it.
Simply add #define MREMAP_MAYMOVE 0

tgingold · 2019-11-15T05:53:43Z

How could the issues on freebsd be investigated ?

Well, I suppose the simplest would be me to install it...

eine · 2019-11-15T06:04:48Z

How could the issues on freebsd be investigated ?

Well, I suppose the simplest would be me to install it...

How about http://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/12.1-RELEASE/amd64/Latest/?

endofexclusive added 3 commits November 14, 2019 20:59

configure: ortho_flags for FreeBSD

6cdffc2

ortho: use mremap() only if available

6b6dd99

Not available on FreeBSD 12 for example

eine added Backend: mcode GHDL using in-memory code generation Build: Makefile Building GHDL using makefiles (standard Linux, Unix, MacOS environments) OS: FreeBSD labels Nov 14, 2019

tgingold requested changes Nov 15, 2019

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow building GHDL mcode on FreeBSD #1020

Allow building GHDL mcode on FreeBSD #1020

endofexclusive commented Nov 14, 2019

eine commented Nov 14, 2019

endofexclusive commented Nov 14, 2019

eine commented Nov 14, 2019

tgingold Nov 15, 2019

tgingold Nov 15, 2019

tgingold Nov 15, 2019

tgingold commented Nov 15, 2019

eine commented Nov 15, 2019 •

edited

Allow building GHDL mcode on FreeBSD #1020

Are you sure you want to change the base?

Allow building GHDL mcode on FreeBSD #1020

Conversation

endofexclusive commented Nov 14, 2019

eine commented Nov 14, 2019

endofexclusive commented Nov 14, 2019

Executive summary after exploring the testsuite

ghdl_llvm on master

ghdl_llvm on pr/mcode-on-freebsd12

ghdl_mcode on master

ghdl_mcode on pr/mcode-on-freebsd12

Details

On master building with LLVM backend

On pr/mcode-on-freebsd12 building with LLVM backend

Observation

Testsuite on ghdl_mcode

eine commented Nov 14, 2019

tgingold Nov 15, 2019

Choose a reason for hiding this comment

tgingold Nov 15, 2019

Choose a reason for hiding this comment

tgingold Nov 15, 2019

Choose a reason for hiding this comment

tgingold commented Nov 15, 2019

eine commented Nov 15, 2019 • edited

`ghdl_llvm` on master

`ghdl_llvm` on pr/mcode-on-freebsd12

`ghdl_mcode` on master

`ghdl_mcode` on pr/mcode-on-freebsd12

eine commented Nov 15, 2019 •

edited