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.

In D14193#297843, @fsu wrote:

I am more prefer to initialize stack variables immediately after declaration, but, seems like it is not so perfect practice.
Ok.

Fix compilation.

In D10035#297350, @brooks wrote:

At a glance this seems fine. Is it stalled for review or abandoned?

This is small enough that shouldn't affect upstream merging (also the code is very FreeBSD-specific).
It also respects the general objective of the code.

In D13964#293442, @fsu wrote:

In D13964#293380, @pfg wrote:

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.

I haven't looked at ext4 for a while but most of those features seem to require some obscure collaboration from the kernel, that is out of the scope of the driver. There's also the issue that most of the interesting enhancements in linux assume there is journalling.

I am not sure, that journal feature is required for non-native file system, also it will be difficult to test it.

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.