manu pointed you @jbeich had beat me to this

Seems generally reasonable. Fortunately we have't had RESERVED syscall numbers for long so this isn't violating our guarantee too badly.

Sigh, I committed the changes and had pasted in the wrong review url. Accepting so I can close...

Arg, I somehow included this review number in a ports commit message. I'll open a new one.

In D30967#696806, @arichardson wrote:

I guess we could also merge */Makefile.inc to the main makefile, but this change was simpler

This makes sense to me. You probably might as well fix the bogus extra space in front of vis while you're here.

• rebase, regen generated files

s/allocation/page/

I've to update the description to match what I believe is currently implemented. I've not mentioned largepages by name because I can find no documentation of them to reference. I've also attempted to improve the description of prot (that will be a separate commit).

• mprotect.2: Update text for largepages
• mprotect.2: Improve the description of prot

I briefly considered the possibility that there might want to be some sort of force flag, but I don't see a lot of value.

In D30442#683682, @kib wrote:

It was completely wrong before adding largepage support, but now it is closer to being correct than not. I propose to remove the second sentence from your diff, and change 'an entire region' to 'an entire large page'.

Thanks for the better wording. As you noticed, LLD_LINK doesn't do anything in llvm10 and later (the link is made unconditionally). I think I'd like to go ahead and commit the change to llvm90 immediately because I don't think it will trigger rebuilds, but check that there aren't other changes I should be making to 11-12 before deleting the options since that definitely triggers a rebuild in poudriere.

Can we please encourage per-file or per-group consistency? Patches are annoying to read when the a group of #defines randomly switches between styles.

"definfed" in the title line.

We could also do something gross like adding an && !defined(DONT_OVERRIDE_TOOLCHAIN_FOR_CROSS_TOOLCHAIN). At the moment, I just want something that works since the current code makes it impossible to cross build cmake ports.

In D29236#669332, @bapt wrote:

Doing this we might miss cases where the cmake uses is inherited from a USES (which does not exist in the ports tree - yet ? but is a valid usage)

Superseded by D29742

I'd assumed slist-apply was late because if it's just doing things like generating a file to install, it's annoying to have to re-run the whole build to test it (consider llvm-wrapper.sh in all the llvm ports). If moving it early is fine then I'm happy with that.

• pmc_op: Add freebsd32 stub

• Rename syscall to pmc_op
• libpmc: Call pmc_op directly

ping

• Move apply-slist-early slightly later...

• Rebase

I've moved apply-slist-early to configure and put it before create-binary-wrappers on the grounds that you might well want to perform substitutions in a wrapper script.

• Move apply-slist-early to configure stage

In D29237#662456, @mat wrote:

Mmmm, if the idea is to have the files available for configure and build, please hook them up when they are needed, in the configure stage, between configure-message and pre-configure runs, not in the extract phase.

With this change, the following (modulo cut and paste damage) lets me cross build llvm-devel:

@@ -60,6 +63,20 @@
                -DPYTHON_INCLUDE_DIR=${PYTHON_INCLUDEDIR} \
                -DPYTHON_LIBRARY=${LOCALBASE}/lib/lib${PYTHON_VERSION}m.so

Seems sensible to me. I'm not entirely sure we shouldn't just silently ignore unknown tags unless some sort of --picky option is specified.

I'm using this to populate a CMake toolchain file for cross building. It's tidier than doing a manual SED doing the same thing.

With this I've been able to construct a set of changes to llvm-devel to allow it to cross build a dependency-free version of clang which is most of the way to having base/llvm* ports suitable for use with a root fs containing no compiler.

Small nit in commit message: Missing ( in the second paragraph.

I think this is like to need a ports exp-run.

Thanks for the gitlab reference, being able to cherry-pick the commit and preserve author data was helpful.

This seems reasonable. Adding Alex in case he's interested (we might want to use this in cheribuild to match src paths match smbfs mounts).

It seems worth adding a reference to mtree.

IMO these tests are extremely dubious and fragile. Embedding cc/c++/cpp seems most likely to work at all. I think I've proposed something like this in the past.

The syscalls.master bits look fine.

Committed in R10:bfc99943b04b46a6c1c885ce7bcc6f235b7422aa

• Rebase
• Use a slightly more compact style

• Rebase
• s/rsrvd/reserved in makesyscalls.lua

I've updated the diff (it's three commits). I ended up using RESERVED since the only thing a long name causes issues with is alignment of the comment at the top of syscalls.master.

• Update comment saying to add syscalls at the bottom

• syscalls.master: Add a new syscall type: RESERVED
• Reserve gaps in syscall numbers for local use

In D27988#633155, @kib wrote:

Again, why not push cleanup separately.