armv7 target /sys/kern/kern_linker.c build failures for main in personal build (KLD_DPF with __func__ used in argment as if it produced a string literal)
Date: Sat, 19 Sep 2026 19:34:23 UTC
Both non-debug and debug builds got the issue:
--- kern_linker.o ---
/usr/main-src/sys/kern/kern_linker.c:340:16: error: expected ')'
340 | (__func__ ": registering exterror categories for %s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:340:6: note: to match this '('
340 | (__func__ ": registering exterror categories for %s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:357:16: error: expected ')'
357 | (__func__ ": unregistering exterror categories for
%s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:357:6: note: to match this '('
357 | (__func__ ": unregistering exterror categories for
%s\n",
| ^
Building
/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.armv7/sys/GENERIC-NODBG-CA7/kern_module.o
Building
/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.armv7/sys/GENERIC-NODBG-CA7/kern_mtxpool.o
2 errors generated.
*** [kern_linker.o] Error code 1
--- kern_linker.o ---
/usr/main-src/sys/kern/kern_linker.c:340:16: error: expected ')'
340 | (__func__ ": registering exterror categories for %s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:340:6: note: to match this '('
340 | (__func__ ": registering exterror categories for %s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:357:16: error: expected ')'
357 | (__func__ ": unregistering exterror categories for
%s\n",
| ^
/usr/main-src/sys/kern/kern_linker.c:357:6: note: to match this '('
357 | (__func__ ": unregistering exterror categories for
%s\n",
| ^
Building
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/sys/GENERIC-DBG-CA7/kern_mutex.o
2 errors generated.
*** [kern_linker.o] Error code 1
I'll remind that, in C, __func__ is a reference to an implicit, function
local:
static const char __func__[] = "function-name";
and is not a string literal. One cannot concatenate __func__ with a
string literal via adjacent placement (that would be a language extension).
Note: aarch4 did not report such a failure when built from the same
source tree on the same machine. an amd64 system also did not report the
failure when based on a copy of the same source tree.
My prior context predated:
author Brooks Davis <brooks@FreeBSD.org> 2026-08-03 16:50:01 +0000
committer Brooks Davis <brooks@FreeBSD.org> 2026-08-03 21:43:23 +0000
commit 295f10230903d54c700518467c4ea4492f5c4faa (patch)
tree fc76723160a417b8aa23121ff7a8a4e29f634527 /sys/kern/kern_linker.c
parent bbf95a9b8481e41a99b301e12338e1cda6915a01 (diff)
exterror(9): dynamic kernel categories
Make it possible to define categories without compiling their
paths into libc (important for third-party modules). The
EXTERR_CATEGORY_DYNAMIC macro can be defined to a string describing the
compilation unit (generally the path relative to src/sys) which takes
the place of EXTERR_CATEGORY.
These strings are assembled in linker sets with category numbers
assigned at system startup or module load time. The strings can be
retrieved from the kern.exterr.categories.<category> sysctl.
Reviewed by: kib
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D58237
The code from that is:
+static void
+linker_file_register_exterr(linker_file_t lf)
+{
+ struct exterr_cat **start, **stop;
+
+ KLD_DPF(FILE,
+ (__func__ ": registering exterror categories for %s\n",
+ lf->filename));
+
+ sx_assert(&kld_sx, SA_XLOCKED);
+
+ if (linker_file_lookup_set(lf, "exterr_cats", &start, &stop, NULL) != 0)
+ return;
+
+ exterr_cat_register_module(start, stop);
+}
+
+static void
+linker_file_unregister_exterr(linker_file_t lf)
+{
+ struct exterr_cat **start, **stop;
+
+ KLD_DPF(FILE,
+ (__func__ ": unregistering exterror categories for %s\n",
+ lf->filename));
+
+ sx_assert(&kld_sx, SA_XLOCKED);
+
+ if (linker_file_lookup_set(lf, "exterr_cats", &start, &stop, NULL) != 0)
+ return;
+
+ exterr_cat_unregister_module(start, stop);
+}
+
--
===
Mark Millard
marklmi at yahoo.com