In D20533#443680, @emaste wrote:

Perhaps we should put a comment at the beginning of this file explaining that it's not a perfect match for style(9) and providing an example or two of how it can be used?
I had a much less comprehensive .clang-format and used it like so:

clang-format file.c > formatted.c
kdiff3 file.c formatted.c &

and then just edited file.c to manually apply appropriate changes.
The .clang-format here is much better than what I had and gets quite close. Some changes it made and some comments on those changes below, but my overall comment: this is indeed already useful as is for work I have in progress.

 struct glyph {
-       TAILQ_ENTRY(glyph)       g_list;
-       SLIST_ENTRY(glyph)       g_hash;
-       uint8_t                 *g_data;
-       unsigned int             g_index;
+       TAILQ_ENTRY(glyph) g_list;
+       SLIST_ENTRY(glyph) g_hash;
+       uint8_t *g_data;
+       unsigned int g_index;
 };

We have a mix of lining up and not lining up variable names in the tree; examples in style(9) have them lined up.

In D18291#438265, @emaste wrote:

In D18291#438263, @arichardson wrote:

In D18291#438254, @jhb wrote:

I'm pretty sure we use 4byte alignment (.balign 4) to ensure its aligned to one instruction.

My argument for just removing it is that if we're linking in an object file with an .init or .fini containing part of an instruction we're going to fail at startup (or shutdown) anyway so it doesn't matter. In cases where the objects are well-formed the alignment directive is redundant, and other architectures (except sparc64) don't specify it so MIPS ought not as well.

I agree, dropping it should be completely fine since the individual files should implicitly have alignment 4. If not then the compiler is doing something wrong.

In D18291#438254, @jhb wrote:

Did you test this? In CheriBSD we are definitely using the equivalent of .align 16. MIPS instructions are only 4-bytes, so instruction alignment as described in your latest comment would seem to imply that '.align 4' was redundant?

LGTM.

Lgtm but I would wait for @bdrewery or @emaste to also review.

In D16868#415223, @bdrewery wrote:

In D16868#415222, @bdrewery wrote:

In D16868#415167, @bdrewery wrote:

In D16868#415150, @bdrewery wrote:

Has this turned up any bad pipelines in Makefiles?

Ah right there is that dd one from a while back.
Now that pipefail is in we could do this a lot simpler like tools/install.sh works.
I don't think it needs to be a MK_ option.
It doesn't need to install.
Maybe something like this could work in tools/sh.sh that we just set with __MAKE_SHELL=?

#! /bin/sh
set -o pipefail 2>/dev/null || :
exec "$@"

Hmm set -o pipefail || : doesn't actually ignore the error.

# sh -ec 'set -o pipefail || :; echo test'
set: Illegal option -o pipefail

:(

This works and avoids a fork and error.

x=$(set -o); case $x in *pipefail*) set -o pipefail ;; esac

I'm trying to avoid adding fork/exec/grep overhead to a sh_pipefail.sh script since it will be executed a lot.

Ping?

Also adjust make_dtbo.sh

It worked afterward I made this change but I'm not 100% certain that it was because of this patch (not using META_MODE).

Rebased and fixed typo in info message

ping?

Looks like we also need a newer version of libcasper.h in -legacy to build on 11

Avoid warning message if /usr/include/capsicum_helpers.h doesn't exist

In D16842#381595, @jhb wrote:

In D16842#381593, @bdrewery wrote:

In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

It's called TARGET_TRIPLE

I feel like TARGET_TRIPLE alone doesn't work. For example for mips I have to use 'mips-unknown-freebsd12.0' for lib32 when TARGET_TRIPLE is 'mips64-unknown-freebsd12.0'.

In D16842#381591, @bdrewery wrote:

I don't get emails for phabricator emails.
I do get and respond to IRC usually instantly.
Please get my feedback for further build changes.

Fixed comments.

Will split this into various separate reviews once https://reviews.freebsd.org/D16815 lands.

In D17799#380377, @arichardson wrote:

In D17799#380357, @dim wrote:

I've already integrated the upstream fix for lld into the clang700-import branch, and a review is already open for including the same patch into the llvm70 port. Is there any need for this particular change?

Well, I think avoiding calls ld -r and objcopy for something that can be done with a few lines of inline assembly is a good idea. There have been tons of bugs in lld -r in the past (and others probably still exist but haven't been hit yet).

Also this bug makes it impossible to build with the latest released version of clang on Linux/macOS.

In D17799#380357, @dim wrote:

I've already integrated the upstream fix for lld into the clang700-import branch, and a review is already open for including the same patch into the llvm70 port. Is there any need for this particular change?

Fix build of some kernels by adding "stat" to the required tools

ping?

ping?

No longer needed

Style fix

No longer needed

Fix typo in comment

Simplify and remove .MAKE.OS check

ping?

ping?

Ah that makes sense. If make kernel-toolchains is already a requirement for MAKE_JUST_KERNELS, I'll drop this and just run make kernel-toolchains first in cheribuild.

In D17779#380013, @imp wrote:

I'm uneasy about doing this automatically... What if I already have a good compiler? Last thing I want is to rebuild clang a bazillion times while I'm iterating through kernel build issues on N platforms.

• rebased on HEAD
• fixed an incorrect defined()

Ideally we could place the padding outside of the section instead of inside and then just use <=. However, the linker can place any orphan section inbetween so there might be some relocations...
Since that is not possible this solution looks fine to me.

In D17682#378395, @mmacy wrote:

In D17682#378334, @arichardson wrote:

Yes, the current set of patches required (for macos and linux) can be seen here: https://github.com/arichardson/freebsd/tree/crossbuild-aug2018?files=1

That's excellent. How much more work would it take to get FreeBSD or parts of it building in some of the various public Linux centric CI systems?

Yes, the current set of patches required (for macos and linux) can be seen here: https://github.com/arichardson/freebsd/tree/crossbuild-aug2018?files=1