In D26473#608811, @ngie wrote:

Non-blocking thought: can this use sem_post/sem_(timed)?wait instead of spinning in busy-loops waiting for threads to start?

It seems like GCC needs a valid goto *addrof_label in order to take the address of a label inside the function rather that at the start. Not sure if that really matters though:

In D27290#611349, @uqs wrote:

In D27290#611021, @arichardson wrote:

In D27290#610937, @uqs wrote:

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

Looks like using the pre-installed system packages still takes 22s instead of 40ish? But if it works with system-provided packages that's probably better than installing a specific version.

Speaking of which. debian/ubuntu has a bmake package, it would be great if we could use that. homebrew has a bmake package as well.

We could also use a cache and store the bmake artifacts in between runs, but I haven't fully wrapped my head around caching in Travis or Github yet.

Last time I tried the Ubuntu bmake package it did not work, but that may have improved since. However, I think there is also value in checking the bmake version bundled in the source tree works.

In D27290#610937, @uqs wrote:

Microsoft's money isn't my concern here, but rather the FreeBSD developer time, so this stuff should be as fast as possible.

Here's what I had in mind, I tried to get gcc to play ball, but gave up on that. It would be worthwhile for a buildworld, I'd say.

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

I guess the problem is that -isystem now moves ${WORLDTMP}/legacy/usr/include after all other -I includes:

LGTM, but not sure if this will break SVN->git conversion again.

The failures can almost be worked around by using --with-defshell=/bin/bash, so another option would be to configure with bash as the default shell on ubuntu and relax the vardebug test:

--- /local/scratch/alr48/tmp/bmake/unit-tests/vardebug.exp	2020-10-31 22:57:02.000000000 +0000
+++ vardebug.out	2020-11-17 11:19:20.201759664 +0000
@@ -77,7 +77,7 @@
 Var_Parse: ${UNDEFINED} with VARE_UNDEFERR|VARE_WANTRES
 make: "vardebug.mk" line 53: Malformed conditional (${UNDEFINED})
 Global:delete .SHELL (not found)
-Command:.SHELL = /bin/sh
+Command:.SHELL = /bin/bash
 Command:.SHELL = overwritten ignored (read-only)
 Global:.MAKEFLAGS =  -r -k -d v -d
 Global:.MAKEFLAGS =  -r -k -d v -d 0
Failed tests: vardebug
*** Error code 1

Also would it be possible to include the missing/sys/cdefs.h file in the next import so that it can build on Linux? This would allow me to remove some hacks from the bootstrap make.py script.

In D27234#608288, @sjg wrote:

The ksh issue is already fixed in bmake-20201114
can you try http://www.crufty.net:/ftp/pub/sjg/beta/bmake-20201114.tar.gz to confirm the other issue is also fixed

GitHub's CI shows me that this has been broken since https://github.com/freebsd/freebsd/commit/75b18a5d5f4a8355e59917a640f80db350e178d3

git blame points at https://github.com/CTSRD-CHERI/cheribsd/commit/4d2d3d6dc7e7e38ce6403654f0f998e79ca4e0c4

Looks good to me.

In D27153#606346, @lwhsu wrote:

In D27153#606212, @arichardson wrote:

In D27153#606211, @emaste wrote:

I think this is fine in principle, but ideally would be a run-time instead of build-time check.

We should also find a way to ensure we add good fuzz testing via CI at some point (i.e., don't just commit this and never revisit).

There is a SKIP_TEST_FUZZ variable that could be set in functional_test.sh: https://github.com/freebsd/freebsd/blob/4e9412c9eec32da012f06fd9553b1d14232227ae/contrib/libarchive/libarchive/test/test_fuzz.c#L63

I just thought we might as well skip listing those test if we aren't going to run them.

I also think this is fine. There are some buzz tests in libarchive weren't stable, for example, https://bugs.freebsd.org/241662 (They recently become more stable in both ci.freebsd.org and upstream.)

The only comment from me is we're using LIBARCHIVE_INCLUDE_TEST_FUZZ vaiable here, and for GoogleTest we use a toggle with another naming scheme. Is there a way to easily build, install and default to run all the tests in the code base? Say, all can be enabled by a toggle like WITH_EXTRA_TESTS that will be useful to check all the available test codes in the tree, and do improvement and categorizing, for the purpose that we want to create lists of tests with different purposes.

In D27153#606211, @emaste wrote:

I think this is fine in principle, but ideally would be a run-time instead of build-time check.

We should also find a way to ensure we add good fuzz testing via CI at some point (i.e., don't just commit this and never revisit).

ping @ngie ?

This may help clang: https://reviews.llvm.org/D80392

In D27088#604714, @adrian wrote:

Hm, wanna see if it compiles using gcc-6 instead? mips32 SHOULD compile now, as long as you disable ZFS.

(I'm still working on the GCC build fixes.)

Or if you want until the weekend, I can test this out in my local mips32 + gcc6 setup for you.

Did you want to poke this upstream to llvm and find out what we're doing wrong or if it's a toolchain bug?

In D27088#604704, @arichardson wrote:

MALTA currently fails with

ld: error: /tmp/inckern-c4cc73.o:(.eh_frame): PC offset is too large: 0xfffffffeff7eae24

I guess I'll just not remove the .cfi annotations for that function. Although I don't quite understand why I'm getting that error.

MALTA currently fails with

ld: error: /tmp/inckern-c4cc73.o:(.eh_frame): PC offset is too large: 0xfffffffeff7eae24

I guess I'll just not remove the .cfi annotations for that function. Although I don't quite understand why I'm getting that error.

In D27088#604702, @arichardson wrote:

In D27088#604697, @adrian wrote:

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

I've not tried building MIPS32 but I don't see why it would be any different from MIPS64. It just tells the compiler to place some extra data in .eh_frame.

In D27088#604697, @adrian wrote:

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

Drop unnecessary change

In D26978#601758, @cem wrote:

LGTM. You could go ahead and commit the changes that work with current clang-format separately, if you're waiting on upstream for the AllowAllArgumentsOnNextLine.

Do you know if there is a mechanism to get the type and qualifiers on an independent line before the function name? That jumps out as a missing piece in both examples. Thanks!

ping?

ping?

Thanks for working on this! Hopefully this means fewer atf-sh tests in the future. Tests written in shell are unnecessarily slow and massively increase CI time on emulated platforms such as QEMU (and even more so on CHERI QEMU since we have to emulate tagged memory).

Fix json output

Accidental duplicate

Use -O0 instead and update comment

In D26751#599214, @ngie wrote:

In D26751#599053, @arichardson wrote:

In D26751#599033, @dim wrote:

Might as well go full -O0. :)

Running the tests at -O2 in QEMU amd64 took:
44.52 real 27.28 user 13.96 sys
Changing it to -O1 makes it
91.80 real 73.32 user 14.28 sys
and -O0 results in
109.46 real 90.08 user 14.38 sys

So we might as well use -O0 since it doesn't seem to make much of a run time difference but has a big impact on compile time :)

What is the disk space size like in each case?

update

In D26751#599033, @dim wrote:

Might as well go full -O0. :)

ping?

I think this option should be set to on in the default ci.freebsd environment, but most users probably don't need to run these tests.

In D26776#597226, @bdrewery wrote:

Please don't. This is such a huge niche micro optimization. -j1 isn't normal and I don't see this being worth the maintenance cost.

Plus it breaks downstream builds and probably ports.

Stop hardcoding stuff that is harder to maintain!

• fix typo in filename

In D26779#597081, @kp wrote:

Simple /usr/tests/sbin/pfctl % sudo kyua test (So I start kyua in the /usr/tests/sbin/pfctl directory)

• set errno to zero before read() loop

In D26779#597070, @kp wrote:

I've not yet looked into the why, but this seems to fail for me:

pfctl_test:pf0001 -> failed: /usr/src/sbin/pfctl/tests/pfctl_test.c:100: Expected errno 0, got 2, in count == 0 && "Should have reached EOF" [0.007s]

• fix license header

remove another unused file