Thanks for picking this up, you went a similarly direction to what I was thinking, but I've been at a conference and traveling home so distracted.

I've created a tracking bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278879.

In D45086#1029238, @des wrote:

Would you like me to commandeer this?

• sort arch list
• examine X_COMPILER_TYPE if defined and COMPILER_TYPE iff X_COMPILER_TYPE is not defined.

I think I've addressed everything. There might be argument for just using a pragma push/pop to disable the warnings instead of adding checks, but I've already spent more time then this code is worth.

Fix strftime log message. Prefer sizeof(buffer) to bare MAXPATHLEN.

Graturiously check the return of sprintf because glibc's headers
require it when compiling with gcc.

The easiest way to address this would probably be a cross toolchain wrapper script that picks the right compiler when -m32 is on the command line, but just disabling it for now seems reasonable. (I'm trying to test make tinderbox with gcc13 and this was one of the issues I encountered.)

actually install symref.awk

Eliminate the use of printf

• allow local override of ${SHLIB_NAME}.symbols (requested by @sjg)
• don't hide symref files (requested by @kib)

Avoid a couple compiler invocations to create empty object files

These symbols are amd64-only

With D45052 committed, this passes a make CROSS_TOOLCHAIN=llvm18 -DWITHOUT_TOOLCHAIN -DMAKE_JUST_WORLDS -j40 tinderbox run. I'll kick off a full run over night in case there are issues in the toolchain bits, but I think this is ready to land. We have had several regressions since I first posted this review so getting this in is clearly valuable (admittedly, a number of which were my fault in merging patches I failed to notice had gotten out of date.)

Rebase, bump doc date

This seems to be the result of botched testing. D45052 replaces it.

If we allow rfork we should presumably allow vfork too. Have you asked @rwatson or @jonathan why they weren't allowed in the first place?

Move extendxftf2 and trunctfxf2 removal to D45034

I've moved the extendxftf2 and trunctfxf2 removal to D45034.

@arichardson made a big change upstream that impacted the upstream conditional for extendxftf2 and trunctfxf2 prior to llvm18's release. I might want to make that change a separate commit.

Only complain about missing symref file in the current directory.
Otherwise, it's too noisy in lib/libc due to libraries in the tests tree.

Exclude private symbols

In D44271#1026327, @kib wrote:

In D44271#1026288, @brooks wrote:

In D44271#1025583, @kib wrote:

Private versioning namespace should be filtered out, I think.

I think we want to know when that set changes even if we don't consider it part of the ABI, but I probably could be persuaded otherwise. I might want to make it optional so libraries can opt in and others opt out.

At least it should be split into two parts somehow, either textually in the same file, or putting the FBSDprivate into aux file at all.

Explain why we can't use readelf -D and add symbol visibility.

In D44271#1025583, @kib wrote:

Private versioning namespace should be filtered out, I think.

Review suggestions from @sjg

typo fix

• Rewrite with readelf and an awk script. Weak vs global and symbol type are now tracked. It's also a bit less grotty as readelf implementations are more similar.
• Make the symref files dot-files so they clutter the tree less.

I'm going to switch to using readelf

This revision does stand alone though.

Presumably want to remove the actual option and tools/build/options/WITHOUT_CAPSICUM?

In D44373#1013871, @trasz wrote:

Can you describe the dlopen threat model a bit more? My assumption is, a typical Capsicum-aware app wouldn't be setting the rootdir/curdir at all. Or, if it does, it could call cap_enter(2) again before calling dlopen(3), clearing those vnodes.

What is the value of MK_VIMAGE_SUPPORT over MK_VIMAGE? We now have an unused MK_VIMAGE. What will it control?

Thanks for the review, I plan to push Monday.

Separate STATICOBJS lines