I haven't needed this when building mips64 on clang 6. clang 7 can't build mips due to a different regression (but not in this file).

I would probably not fiddle with the sysctl in crypto check FWIW. I originally wrote it to test ccr0, not "soft". Will look at other parts of the patch in a bit.

• Merge into devel/gdb port under the python option.

The only reason I have it separate is that I anticipate (hope) that it will change more quickly than gdb if other people contribute more pretty printers, etc. (It only covers a few STL classes now and has large gaps) Having a separate port just means people can update that package independently. That said, the .pyc thing (in case you run gdb as root against a C++ program) is a valid point (and one that can't really be solved as a separate port), and probably there just won't be but so many port revision bumps. I don't mind moving it into devel/gdb. Would you want it as a separate option (that "implies" python in ports speak) or just have it be part of the existing python option?

• Rename port to devel/libcxx-gdbpy to match github repository. This also makes %%DATADIR%% patch the data directory perfectly simplifying the plist.
• Remove one layer of directories in the installed tree.
• Reverse the dependency with regards to gdb by making devel/gdb depend on this port if python is enabled in the gdb build. This means that folks installing gdb will get libc++ helpers out of the box on platforms using libc++. This assumes that these helpers are useful.

It's probably fine, but I wonder if it wouldn't be more readable to just use getline() instead. I think you'd end up with something like:

Testing arcanist.

Arguably the dependency should perhaps go the other way with the GDB port having an option to install this package as a dependency.

I think listing a lot of folks will start to get unreadable. I think we can start with the existing language and just use some common sense (if a couple of folks who aren't random committers approve userland changes, then that's probably fine). If we have to nail it down further in the future we can revisit it then.

Ping?

I'm generally happy with this. The #if 0 -> #ifdef CRYPTO_DEBUG change still seems unrelated, but I don't care strongly about it either way.

Looks good to me.

(This one I understand well enough to sign off on)

In D18677#402462, @kan wrote:

I wonder what this does to, say, arm-none-eabi-gcc? It, in somewhat misguided manner, uses powerpc64-gcc as the base.

Thanks! Hopefully this means 'grep -c ENOSYS' in bhyve is now zero. :)

Adding bdrewery@ and bapt@ in hope of getting some review. Not sure if there is another person who would be qualified to review GCC patches.

I stopped saying "same" after a while to avoid being too repetitious. I think it would make sense to have one commit that first fixes existing places not yet using helpers to use the helpers by replacing all uses of cap_rights_limit and cap_ioctls_limit with the helper variants. I would keep the == -1 checks though. The syscalls are defined to return -1 on error, not a random -ve value. From cap_rights_limit(2):

On SMP systems the invalidate_range()'s here would seem to be more efficient since you can batch up the IPI's. I almost wonder if it wouldn't even be better to just do a single invalidate_range at the end instead of dealing with va_next and trying to be perfect about avoiding invalidation of ranges that weren't mapped. The only other call to pmap_remove_l3() in pmap_ts_referenced() is also followed by a call to pmap_invalidate_page(), so I wonder if removing pmap_invalidate_page() wouldn't be the better change?

To avoid the need for 3 separate constants you could just make the software crypto code switch on the key size to pick an auth_hash *. This would require the key during session setup, but that's ok I think. GCM already requires it I believe. It would be ok I think to have the .type members of the 3 auth_hash's all use the same value. Eventually in my ocf_rework branch the goal would be just to say that you use AES-CCM (or AES-GCM) as your cipher and the corresponding MAC is implied without needing to be specified explicitly (so the 3 constants then become unused entirely). However, we aren't there yet, so we probably need at least one constant for now.

In regard to KAT vectors. I think it would be fine to use the approach in the python tester. It pulls the test vectors from a security/nist-kat port, so you would need to update the port to include the relevant test vectors (if it doesn't already) and then modify the python script Conrad mentioned earlier to exercise the new vectors. I think you can probably look at how the script handles GCM to get a sense of what is needed.

One weird oddity. mips uses vm_page_free_zero() for it's top-level page but it doesn't zero it first. arm64 does the same. 32-bit arm v6 just leaks the pages (???), i386 uses vm_page_free() instead of vm_page_free_zero(). sparc64 uses vm_page_free_zero() without zero'ing the pages.