In D30845#694140, @kib wrote:

For the bhyve patch above, why is it useful? As I understand, this vmspace/pmap is never going to be activated at all, so why claiming that TLB invalidation not needed helps? Also, for ARMv8, SMP TLB invalidations do not require IPI, this is why I was surprised that such optimization is ever helpful.

In D30845#694134, @andrew wrote:

You can see the use in bhyve in https://github.com/CTSRD-CHERI/freebsd-morello/commit/d12af6f53e9c9ba08d80974be2fbce7fa9381f95#diff-1c77bb82662186164af0461f49f764096e3c3bd3d3f324a2db019d242cbdb3de

Is there anywhere in the vm code it would make sense to call pmap_pre_destroy? If so I can look at making it a MI interface.

(Tinderboxed.)

In D30175#693715, @donner wrote:

May I ask you to provide a full context diff, please?
It's much easier to review.

You can see the use in bhyve in https://github.com/CTSRD-CHERI/freebsd-morello/commit/d12af6f53e9c9ba08d80974be2fbce7fa9381f95#diff-1c77bb82662186164af0461f49f764096e3c3bd3d3f324a2db019d242cbdb3de

• KASSERT we don't mark the kernel pmap as dead
• Remove a PMAP_ASSERT_STAGE1 that shouln't be part of this patch

Thanks Rainer.

last chance for changes

fix static builds & pet port

In D30842#694103, @arichardson wrote:

I wonder if simply exporting an undef weak symbol from libc.so (without defining it) would also work.

In D30842#694092, @kib wrote:

I do not like it, and in fact think that the drawbacks overweight the supposed benefit.

First, it would break things like dlsym(NULL, "environ") when done not from the main binary. Initially I thought that it would also break e.g. LD_PRELOAD=libc.so binary but it seems that it wouldn't any more than other cases.

Second, our interpretation of weak symbols at runtime as having lower precedence for interposing than non-weak symbols is non-standard. It is probably too late to try to fix that, but at least we should not introduce new cases of use.

Third, the references from DSO to envrion, linked with such libc, gets versioned. I did not looked how it is actually resolved, but I am surprised that it works for you. It should look for the versioned symbol and bind to libc one.

Solved by R10:054accac71e0944ab588c3ab052bea6947df7885

I do not like it, and in fact think that the drawbacks overweight the supposed benefit.

No problem.

LGTM

Fix getTriple() in freebsd::Linker::ConstructJob()

Please check to see if there's any conflicts between this and what I committed.
I just did a fresh vendor import since just apply the patch wasn't enough and phab sucks and reviewing vendor merges.

Fix text according to Ed's suggestion.

Restore missing {

Created D30861 to have Clang stop linking against _p libraries with -pg for FreeBSD 14 and up. We'll need a similar change for GCC.

update, per jhb. hopefully this catches everything...
also a subtle bug nobody noticed (of passing a va into ...)

In D30848#694017, @cperciva wrote:

This also returns with pd->pd_blkio set to non-NULL. Is this intentional?

do not set pd_blkio to NULL.

You'd be better off testing on i386 than amd64 I imagine.

There is no use of pmap_pre_destroy() in the patch.

In D30833#693776, @emaste wrote:

I tried a quick sanity check of -pg on my ~ FreeBSD 13.0 amd64 laptop, without success:

% cc -pg -O0 -g profil.c
% ./a.out
Segmentation fault (core dumped)

Tested with HEAD in EC2 on arm64:

This also returns with pd->pd_blkio set to non-NULL. Is this intentional?