In D22023#481075, @jhb wrote:

So one thought I had had when looking at this as well (in the context of trying to update libcheri to use Makefile.libcompat which we won't bother with, but meant reading much of this stuff) is that I really feel like we should install /usr/lib<foo> into the normal sysroot instead of a separate sysroot. This means builds of programs can always use the same --sysroot (and it also makes it possible to use the same --sysroot from the obj tree for different ABIs when building out-of-tree programs).

• Re-number stages as part of reordering.

• Use realloc() rather than calloc()+memcpy().
• Limit argmax to prevent overflow (no possible on FreeBSD due to ARG_MAX).

To provide a little more background: We have this feature in CheriBSD to complement a set of (build|install|...)cheri targets forked from the old build32, etc targets before Makefile.libcompat was created. We're in the process of killing that off, but find this functionality useful. Among other things, it lets us build tests for compatibility libraries. It can also aid in bringing up a new compat layer (or base system ABI if you coerce all the programs to build for a compat layer).

In D21971#480075, @arichardson wrote:

I wish the C standard library had some kind of dynamic array so that this is not reimplement in every program...

I wonder if we could use something like the utarray.h macros from uthash?
Could we import the five headers that https://github.com/troydhanson/uthash into contrib and use utarray instead? I know the library is not that efficient since it uses strdup() for all strings that you insert but at least it means not reinventing the wheel.
We already have two copies of uthash.h in the source tree and elftoolchain also includes with utarray.h.

I've merged the tcsh changes in via an update to tcsh 6.21.00 in rS353325.

LGTM.

In D21821#476563, @kevans wrote:

In D21821#476482, @emaste wrote:

Ouch, command substitution in syscalls.conf

Yeah, that will be a little more interesting for non-sh parsers :)

Yeah... Luckily this isn't too bad and I've got it working locally in the lua world, but we really should document what's ok and not ok in these .conf files based on how they're currently done to the best of our knowledge.

One of my new pet peeves after lualoader is giving something a fairly innocuous looking extension that's actually fully flavored and not well-documented as such.

OTOH, I don't know where documentation for this in particular would live unless we started an informational syscall manpage with content like the AddingSyscalls wiki page.

This is rather clever, but I don't like this direction. I'd like to remove the embedding of awk in sh that currently exists and this makes it much harder.

Sorry about this. Fixed in rP512326

See also D21366 which includes an identical review diff. I didn't commit it at the time as my initial deprecation target didn't immediately make sense.

LGTM.

LGTM

I suspect I know what's going on. If vectp % 16 == 8 then when long argc is stuck in front of it per the ABI requirements, the stack is aligned to 16 bytes. I suspect a change was made to require 16-byte alignment as recommend by Intel. A possibly relevant thread (I've only skimmed it) https://lore.kernel.org/patchwork/patch/749568/

LGTM

sys/compat/freebsd32/syscalls.master seems to be missing now...

LGTM

• Remove dead check.
• Return immediatly from the loop if bucket gets to big.

I've now booted on amd64 in addition to CheriBSD.

It would be helpful to generate this diff against HEAD. That would exclude the generated files and the freebsd32 capabilities.conf entry.

• Always follow the allocated path, don't free prematurely.

I've fixed the expression to exclude gcc < 8 and tested on amd64 and riscv.

• Use the correct expression to add -Wno-class-memaccess.

I completely misunderstood what was going on. The in .. excludes gcc 4.2.1 and this is a gcc 8.0+ warning. The incorrect copy and paste meant it worked by accident for 6.4. I'm testing a new version now...

This is breaking the xtoolchain CI jobs https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/10997/