In D17917#382796, @jack_gandi.net wrote:

In D17917#382778, @pfg wrote:

Maybe a sweep with opengrok is a good idea to see where we should be using this.

I don't know about opengrok, but this is a new feature only affecting a small part of the ABI so it seems pretty well contained.

In D17903#382777, @bapt wrote:

In D17903#382776, @pfg wrote:

For the record ...

We really do need to update libedit (from NetBSD).
These changes are welcome but I fear the approach of trying to preserve our changes is not sustainable anymore

Someone brave, and with time, has to take the step of just bringing the NetBSD version ...

I did it once, it is not that hard, and our version right now is not that far from there version is it? for the record, I have also contacted christos@ by email so he can wait on this review.

Maybe a sweep with opengrok is a good idea to see where we should be using this.

For the record ...

LGTM.
(I currently don't have the time to go over to Release Engineering for this though ::-/ )

In D17083#364265, @pfg wrote:

This is likely to cause huge havoc in the ports tree: we created the API and Apple adopted it. Later glibc and NetBSD adopted their own variant.

This is likely to cause huge havoc in the ports tree: we created the API and Apple adopted it. Later glibc and NetBSD adopted their own variant.

In D16722#356962, @kib wrote:

In D16722#356907, @pfg wrote:

In D16722#356897, @kib wrote:

I do not think that functions definitions need to use __restrict. libthr is compiled only with C99 compiler, never C89 nor C++, so direct use of the restrict keyword is fine.

In D16722#356695, @kib wrote:

In D16722#356631, @pfg wrote:

Checked for compliance against POSIX/SUSv4-2018.
Document the changes in the man pages.

In D16722#356491, @kib wrote:

In D16722#356448, @pfg wrote:

In D16722#356440, @kib wrote:

Did you verified include/pthread.h against POSIX/SUSv4-2018 ?

No, I only checked individual functions against the public v2-1997, which came up first in my search.

It does not matter much which version of POSIX you used. I am concerned with the header change to match at least some standard.

Avoid const poisoning the private functions by using __DECONST early.

In D16722#356440, @kib wrote:

Did you verified include/pthread.h against POSIX/SUSv4-2018 ?

Drop the bogus umtx change: instead adopt a couple of __DECONST() in
libthr to workaround the warnings.

May I suggest you add "test" targets to the ports?

(I thought this had been committed already :-/ )

I think you still have to fix the shebang on "configure".

Cool thanks! Please try to upstream the changes when you can.

Good catch!

Thanks! feel free to MFC my previous change.

Abandon: it does seem like we can just remove libssp but I don't have time to dig deeper.

In D15687#340722, @kib wrote:

In D15687#340721, @pfg wrote:

In D15687#340720, @kib wrote:

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

Well, that was the question I was asking myself. I moved libssp along with the other libgcc libs (where it came from) and buildworld still works, I get no missing symbols anywhere.
I theorized that we appear to have added the FORTIFY_SOURCE functions but we are not using them anywhere.

Ports are working still on my machine (11-stable), after building without libssp:

file /usr/lib/libssp_nonshared.a:
/usr/lib/libssp_nonshared.a:: cannot open `/usr/lib/libssp_nonshared.a:' (No such file or directory)

Goal is to have the functional system, and to have it GPL-free is somewhere in the second line.

Yes, I am just trying to identify why current is non-functional without the GPL'd piece.

If you do not provide libssp(_nonshared.a), then you should disable -f option for ssp, which is probably enabled by default in the spec for gcc, and somewhere in c++ for clang.

Thanks, that is a good hint.

In D15687#340720, @kib wrote:

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

In D15687#340674, @antoine wrote:

All ports fail to build with this patch

In D15687#339170, @emaste wrote:

For reference, BSDL __stack_chk_fail in Android https://android.googlesource.com/platform/bionic/+/ics-mr1-release/libc/bionic/ssp.c and NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/misc/stack_protector.c?annotate=1.9&only_with_tag=MAIN.

The libssp subdir should be added only if both MK_SSP and MK_GCC are true; someone who sets WITHOUT_SSP but WITH_GCC should not get it. Also, it seems there are other MK_SSP conditionals that need to be investigated in other Makefiles and share/mk.

In D15687#339162, @brooks wrote:

In terms of exposed symbols (see objdump -T), libssp definitely is a FORTIFY_SOURCE implementation. I've not looked at the code to avoid contamination in case we need a cleanroom one.

For the record: the compiler libssp is not the same as libssp as in NetBSD and bionic's libc, which implements the libc support for FORTIFY_SOURCE.

As a sidenote: one file in bhyve has no license. This is a problem.

I agree with other reviewers: The SPDX changes should be split.

Looks good to me

For the record, his patch first appeared in PR 217560, it's unrelated to the Bug, so I asked for an independent CR.
I will take care of it.

Approved.
Hoping someone else can do the honors though .. I did somethig dumb with my partition table.

There is little interest on this.