LGTM - yes, this links to a 2016 status report and is not relevant to include here anymore.

LGTM

I actually hope that I'll never commit this change

In D127360#3569979, @ldionne wrote:

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

Fine with me from a FreeBSD perspective

However, I am not completely sure how far off FreeBSD 14.0's "freeze" is, e.g. when a stable/14 branch is created, and the main branch is bumped to 15.0.

Sounds good to me. We can bump the .so version in the base system, but how do we treat it upstream (i.e., here in llvm) and in the ports tree?

For reference, we're going to support FreeBSD 13 until Jan 2026.
https://www.freebsd.org/security/

Sounds good to me for FreeBSD (w/ the release note as mentioned by @ldionne) arc4random is ChaCha20 in all supported FreeBSD versions.

LGTM (modulo the lint complaints)

The original author appears to have given up on it. Someone will need to rebase and work on pushing it forward

We need to make sure a test covers this as well, perhaps just enabling lldb/test/API/functionalities/unwind/aarch64_unwind_pac/TestAArch64UnwindPAC.py?

ping

OK with me.

procctl was added as of FreeBSD 10.0, and both 10.x and 11.x are now EOL, so I don't think we need to support for cases where it is not available.

0 is an alias for curproc

As a subsequent change I'll propose using PROC_ASLR_CTL to turn ASLR off and ReExec().

References:
rG:e2ed800d622567b35968a27f8784705fb48190f5
https://github.com/llvm/llvm-project/issues/53256

It greatly harms performance on Linux tmpfs, 0.3s in my 5.2s link.

it is likely Linux specific

We requested an experimental ports build with the start-stop-gc behaviour reverted (i.e., with getZFlag(args, "start-stop-gc", "nostart-stop-gc", false);)

Fine with me, or maybe "A test for Darwin- (and prehaps Windows-)specific behavior."

@jrtc27 and @emaste are both on board that the traditional GNU ld behavior / current 13.0.0 behavior is the future.

FreeBSD used an ancient version of GNU ld (2.17.50, from mid 2000s) until we migrated all target architectures to lld. That old ld defaults to no GC start/stop, we have been using that behaviour for decades.

compatible with GNU ld newer than 2015-10

Similar idea to D77776 (libc++ default if major not specified)

rebase tests

@emaste replied: "However, if GNU ld / gold / lld default to GCing things we could set the option to reenable it in kernel/userland Makefiles."

In D111863#3100654, @lhames wrote:

@joerg @dim @emaste Any further comments on this?

IMO this is worth it for the build time reduction, the size reduction is a nice bonus but not the main benefit.

It looks like this worked prior to 2518433f861f because shouldAssumeDSOLocal has this case:

// PPC has no copy relocations and cannot use a plt entry as a symbol address.
llvm::Triple::ArchType Arch = TT.getArch();
if (Arch == llvm::Triple::ppc || Arch == llvm::Triple::ppc64 ||
    Arch == llvm::Triple::ppc64le)
  return false;

Do we want to share some of these tests between NetBSD and FreeBSD?

Would it be possible to add build bots for FreeBSD so we can test changes like those automatically?

Superseded by e67cbac81211d40332a79d98c9d5953624cc1202 (D68720)

We make this change in FreeBSD's in-tree Clang about 9 months ago (https://reviews.freebsd.org/D27366)

LGTM

With this patch applied BE mips64 FreeBSD builds successfully for me

LGTM, although in FreeBSD we don't have any backwards- or cross-compatibility issues to worry about.

-pg is still supported (see the OPT_pg at line 253), gprof just won't be able to "see into" libc, libm, etc.

LGTM

LGTM

Presumably the MIPS tests changed in 72e75ca343c6f need to be changed back

See https://svnweb.freebsd.org/base?view=revision&revision=352807