tools: default to -cc clang on FreeBSD tests

[kimshrier]

tcc on FreeBSD does not support .symver which causes compile errors for cmd/tools/vtest_test.v.

When this omission gets corrected, we can remove this update but in the mean time, this allows the test to pass. The choice to use clang as the C compiler is because that is the default compiler distributed with the base FreeBSD system.

[spytheman]

Why is it needed?
v cmd/tools/vtest_test.v passes for me on FreeBSD 14.0 .

It only tests the cmd/tools/vtest.v tool, which can be compiled with:
./v -no-retry-compilation -cc tcc cmd/tools/vtest.v without problems too on FreeBSD 14.0 .

The cmd/tools/vtest_test.v file itself, only imports os and encoding.txtar, and those modules do not contain nothing that could cause a tcc problem afaik.

[spytheman]

The reason it worked for me, was that in my FreeBSD VM, I have applied this patch (from https://discord.com/channels/592103645835821068/592106336838352923/1197417932771315822 ) in /usr/include/sys/cdefs.h:

--- /sys/sys/cdefs.h    2023-08-25 13:19:02.607408000 -0700
+++ /usr/include/sys/cdefs.h    2023-11-26 13:42:31.999208000 -0800
@@ -539,10 +539,16 @@
        __asm__(".section .gnu.warning." #sym); \
        __asm__(".asciz \"" msg "\"");  \
        __asm__(".previous")
+#ifndef        __TINYC__
 #define        __sym_compat(sym,impl,verid)    \
        __asm__(".symver " #impl ", " #sym "@" #verid)
 #define        __sym_default(sym,impl,verid)   \
        __asm__(".symver " #impl ", " #sym "@@@" #verid)
+#else
+/* TinyC doesn't implement .symver */
+#define        __sym_compat(sym,impl,verid)
+#define        __sym_default(sym,impl,verid)
+#endif
 #else
 #define        __weak_reference(sym,alias)     \
        __asm__(".weak alias");         \

[kimshrier]

I am running on a stock 14.0 release, so that patch isn't on my system. Thanks for pointing it out.

[spytheman]

As much as I like tcc, because of its speed, the V tests, should pass on a stock FreeBSD, when possible. Thanks for fixing it.

[kimshrier]

I don't see this patch in the main branch of FreeBSD. Do you know who authored it? I don't have a discord account so I can't see the discussion. If it's ok, I can create a pull request for it but I would like to give credit to whoever came up with it.

[spytheman]

I don't have a discord account so I can't see the discussion.

It was done by @bakul .

[bakul]

The patch originally came from Warner Losh. Ideally someone teaches tcc about .symver…. Also note that there is something else broken on arm64 platform for tcc.

Nevertheless it is a good idea to run tests once in a while with tcc as more things are broken now. At one point only tests using atomics were broken and I tracked it down to some interaction with the boen-go-threaded pkg….

[bakul]

I had asked Warner about integrating this patch. He said he his some snag when he proposed it. Kim, I can forward that email separately if you like.

[kimshrier]

Yes, forward me the email. I also run FreeBSD current on a Traverse Ten64, which is an 8-core arm machine. I have been using -cc clang in both of my environments due to tcc having problems. I would be nice to iron some of those out.

[medvednikov]

I don't have a discord account so I can't see the discussion.

@kimshrier that's unacceptable for an open source project, that's why this week I'll be doing a discord bridge to volt.im, which will never require an account to read stuff, and all links to messages will always work. Every single message will by synced from the discord server.

Thanks for improving V on FreeBSD, I'm considering moving my servers to FreeBSD, but I'm a bit afraid of how the big V web services will run on it.

[bakul]

Forwared (outside of github).

Alex, big V web services should be no problem provided they don't depend on third party s/w for which there is no freebsd package. May be you can set up a reverse proxy to send a small fraction of traffic to the freebsd based web server until you're confident it will stand up!

[bakul]

Note also that just moving thirdparty/tcc out of the way is all that it takes for V to use system cc. And not doing so still breaks tests (as the logic seems to be to use thirdparty/tcc if it exists).

[kimshrier]

@medvednikov, I've been running FreeBSD servers since version 2.1.5 so I've learned a thing or two over that time. If you need assistance, I am more than happy to help... subject to time constraints imposed by my day job.

[medvednikov]

Thanks :)

To start, I've just implemented cross compilation to FreeBSD.

Just tested the binaries on a FreeBSD 13.2 server, they work great, even with networking and openssl:

 v -d use_openssl -gc none -os freebsd examples/news_fetcher.v

Right now it requires downloading the entire base.txz (~200MB), but I'll build a minimal sysroot soon.

[kimshrier]

There is one flaky test that bothers me, vlib/v/slow_tests/keep_args_alive_test.c.v. I've looked at it but I don't have enough familiarity with V yet to figure out where the race condition is. I haven't put any production V code on a FreebBSD server yet and this test, which just locks up about 80% of the time, contributes to that reluctance.

[bakul]

Running ktrace on it, I see the following repeating over and over again:

13371 keep_args_alive_tes CALL  nanosleep(0x82757b970,0)
 13371 keep_args_alive_tes RET   nanosleep -1 errno 4 Interrupted system call
 13371 keep_args_alive_tes PSIG  SIGUSR1 caught handler=0x8225e4880 mask=0x0 code=SI_LWP
 13371 keep_args_alive_tes CALL  sigprocmask(SIG_SETMASK,0x82095a70c,0)
 13371 keep_args_alive_tes RET   sigprocmask 0
 13371 keep_args_alive_tes CALL  sigsuspend(0x82095a268)
 13371 keep_args_alive_tes RET   nanosleep 0
 13371 keep_args_alive_tes CALL  getcontext(0x82757b5d0)
 13371 keep_args_alive_tes RET   getcontext 0
 13371 keep_args_alive_tes CALL  thr_kill(0x8d147,SIGUSR2)
 13371 keep_args_alive_tes RET   thr_kill 0
 13371 keep_args_alive_tes CALL  nanosleep(0x82757b970,0)
 13371 keep_args_alive_tes PSIG  SIGUSR2 caught handler=0x8225e4880 mask=0x7ffebed9 code=SI_LWP
 13371 keep_args_alive_tes RET   sigsuspend -1 errno 4 Interrupted system call
 13371 keep_args_alive_tes CALL  sigprocmask(SIG_SETMASK,0x820959c4c,0)
 13371 keep_args_alive_tes RET   sigprocmask 0
 13371 keep_args_alive_tes CALL  sigreturn(0x820959880)
 13371 keep_args_alive_tes RET   sigreturn JUSTRETURN
 13371 keep_args_alive_tes CALL  sigreturn(0x82095a340)
 13371 keep_args_alive_tes RET   sigreturn JUSTRETURN
 13371 keep_args_alive_tes CALL  nanosleep(0x82095ad70,0)
 13371 keep_args_alive_tes RET   nanosleep 0
 13371 keep_args_alive_tes CALL  thr_kill(0x8d147,SIGUSR1)
 13371 keep_args_alive_tes RET   thr_kill 0