We don't need these, they were just forgotten when GCC was removed.

It came from rG:2bb58cb2e0c46298578b02d4448f69e4de166f16 and indeed is not used.
You could bump .Dd in hier.7 if you are so inclined.

LGTM

This looks good to me

OK but I agree with jhb that skipping ahead to removal is fine

As with D44275 no objection but perhaps nm and/or readelf are suitable?

A future commit will use objdump to compare the set of symbols built in libraries with a reference list.

We should update sound(4) to indicate that /dev/dspX.Y are deprecated and will be removed, not just strongly discouraged. That said, we don't list /dev/dsp or /dev/dsp0 in sound(4) right now, only /dev/dsp%d.%d and related. We should add those, and probably also find a better representation than printf's %d

I'd like to reduce the duplication in the cloud image *.conf files but that's not specific to this addition.

This is successful everywhere (i.e. architectures, discounting conflicts with other options that Michael Dexter's option survey will find)?

I'm not 100% certain about the name (_NP suffix vs Apple's _ prefix) but that can always be dealt with later.
I see qnx offers a posix_spawnattr_setaslr(), as well as (bizarrely) POSIX_SPAWN_ASLR_INVERT which toggles the state for the child.

@bz thanks, commit subject line and Reviewed-by's updated.

Now in my staging tree as:

FYI, please generate diffs for reviews with full context e.g. git diff -U999999 or git show -U999999 so that Phabricator will display the additional context on demand. See https://wiki.freebsd.org/Phabricator for more info.

Use 16 and 17 for now, 18 gave me pkg: No packages available to install matching 'llvm18-lite' have been found in the repositories. Will replace 16 with 18 later.

Thanks, this makes it more clear why we do this.

What do you think about something like Run 'freebsd-update [options] install' to proceed? It offers a reminder to include the user's necessary options but retains the example style.

s/Macey/Macy/

This was committed (accidentally referencing D43877) and can be closed.

No objection but I would suggest changing the commit message slightly -- right now it seems to imply that the mere presence of the map file prevents undesired libc/libsys code into rtld, rather than just always having the map file available for the developer to inspect. Or just a comment before the LDFLAGS entry, something like

What do you think about a comment explaining why it is retained? something like "is not required by contemporary linkers, but it is still expected by some third party software build systems."

starting off with this in tools/ makes sense, but we probably want to install them at some point, perhaps making use of them in /usr/sbin/crashinfo.

Done by @manu in 2d2950c889335b24af7a92f3aaf9946de47bb0bc

Makes sense to me. Have you tested make tinderbox?