Are -g kernels compiled with dwarf2 or dwarf4 after this change ? If 4, then /usr/libexec/kgdb becomes unusable, and what about crashinfo ?

Via sys/conf/kern.mk:

#
# Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
# and gcc 4.8 is to generate DWARF version 4. However, our tools don't
# cope well with DWARF 4, so force it to genereate DWARF2, which they
# understand. Do this unconditionally as it is harmless when not needed,
# but critical for these newer versions.
#
.if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
CFLAGS+=        -gdwarf-2
.endif

Further to the comment The default starting in clang v3.4 ... is to generate DWARF version 4, I'm not sure if Clang defaulted to version 4 and someone later added the FreeBSD special case to go back to 2, or the comment is based on a misunderstanding. I may just change the comment to something like Newer compilers generate version 4 by default, but our old /usr/libexec/gdb .... (Other tools have been updated to handle DWARF4.)

Since 12 is already out and using 2, shouldn't that be <= 12?

In D17930#401798, @emaste wrote:

Further to the comment The default starting in clang v3.4 ... is to generate DWARF version 4, I'm not sure if Clang defaulted to version 4 and someone later added the FreeBSD special case to go back to 2, or the comment is based on a misunderstanding. I may just change the comment to something like Newer compilers generate version 4 by default, but our old /usr/libexec/gdb .... (Other tools have been updated to handle DWARF4.)

I remember that we set the DWARF version to 2 first, and when in a later version of clang I tried to bump it to 4, it got very quickly shot down. :) Hopefully it'll be more accepted now.

exp-run requested in PR234887

In D17930#401810, @rpokala wrote:

Since 12 is already out and using 2, shouldn't that be <= 12?

I think it's fine to switch the default when targeting 12 actually. The only tool left which does not handle DWARF>2 is /usr/libexec/gdb, which should be used only for kernel core dumps when the gdb port is not installed, and the kernel build explicitly adds -gdwarf2.

Note, this should be upstreamed as well. @emaste if you didn't do the new LLVM license stuff already, I'll commit it there, when we've reached concensus.

What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* . There are architectures for which modern gdb from ports fails ( by running into bugs in C++ thrown-exception support in the system libgc_s ): powerpc families. (I experiment with using more modern compilers. clang has issues of its own but devel/powerpc64-gcc for powerpc64 targeting is useful for buildworld buildkernel and more. I have a patched libgcc_s that I reported on the lists but most folks do not have.)

In D17930#402006, @markmi_dsl-only.net wrote:

What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* .

libexec/gdb is only intended for crashinfo(8) and the kernel is built with an explicit -gdwarf2 flag so will not be affected by this change. In any case libexec/gdb is probably going away in 13.0 (@jhb can comment).

There are architectures for which modern gdb from ports fails ( by running into bugs in C++ thrown-exception support in the system libgc_s ): powerpc families.

The powerpc* ones don't use Clang (by default), so won't be affected by this change now; we just need to fix the exception issues along with fixing Clang. (Are there PRs for all of the known issues?)

In D17930#405010, @emaste wrote:

In D17930#402006, @markmi_dsl-only.net wrote:

What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* .

libexec/gdb is only intended for crashinfo(8) and the kernel is built with an explicit -gdwarf2 flag so will not be affected by this change. In any case libexec/gdb is probably going away in 13.0 (@jhb can comment).

I hope the powerpc families end up with either libgcc_s fixed or a working libunwind context before this happens for those families. (But I run with a patch for libgcc_s that I published on the lists. This
is separate from clang's additional problems compiling that library: I normally use devel/powerpc64-xtoolchain-gcc related materials to buildworld for powerpc64.)

There are architectures for which modern gdb from ports fails ( by running into bugs in C++ thrown-exception support in the system libgc_s ): powerpc families.

The powerpc* ones don't use Clang (by default), so won't be affected by this change now; we just need to fix the exception issues along with fixing Clang. (Are there PRs for all of the known issues?)

There are llvm submittals for what I know about, both for how libgcc_s is mishandled by clang and for libunwind failing for assembler syntax errors (mismatched standards for notation?).
There have been other clang/llvm submittals as well, several addressed. (At least some of the llvm submittals have matching FreeBSD bugzilla submittals.)

But I do not see a mention of DW_CFA_remember_state or DW_CFA_restore_state in searches of FreeBSD's bugzilla so the libgcc_s issue might note be covered (and is not a llvm issue).
I expect fixing libunwind and switching to using it will be the long term solution: there seems to be not much interest in making libgcc_s work more completely for these until then. Possibly:
not considered worth a testing effort for something so central for contexts that still use that part of libgcc_s. Still, I could extract materials from my list submittals and make a bugzilla submittal
if it seems appropriate.