Recently the following cropped up again. slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering ieee80211_vap_setup\n"); }' dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d", line 1: failed to copy type of 'pr_gid': Conflicting type is already defined slippy# Could this be similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254483 ?
FreeBSD slippy 14.0-CURRENT FreeBSD 14.0-CURRENT #0 komquats-n256887-151abc80cde7: Fri Jul 22 23:00:05 PDT 2022 root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK amd64
I'm able to reproduce this now.
The problem is that CTF/DTrace aren't properly distinguishing bitfield types from their base integer types. If you're unlucky, ctfmerge can merge types in such an order that "unsigned int" refers to "unsigned int : 8" by default, i.e., a lookup by name of "unsigned int" gives you an integer type with a width of 8 bits instead of 32 bits. It so happens that your custom kernel config triggers the problem. I think it's probably best to give bitfield type names an additional qualifier so that the base type name is always unambiguous. Nothing should be looking up bitfield types by name, at least I hope. I wrote a patch which does exactly that and it solves the problem. I'll run it through the DTrace test suite before committing.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1165fc9a526630487a1feb63daef65c5aee1a583 commit 1165fc9a526630487a1feb63daef65c5aee1a583 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2022-08-03 00:32:17 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2022-08-03 00:32:17 +0000 ctfconvert: Give bitfield types names distinct from the base type CTF integers have an explicit width and so can be used to represent bitfields. Bitfield types emitted by ctfconvert(1) share the name of the base integer type, so a struct field with type "unsigned int : 15" will have a type named "unsigned int". To avoid ambiguity when looking up types by name, add a suffix to names of bitfield types to distinguish them from the base type. Then, if ctfmerge happens to order bitfield types before the corresponding base type in a CTF file, a name lookup will return the base type, which is always going to be the desired behaviour. PR: 265403 Reported by: cy MFC after: 1 week Sponsored by: The FreeBSD Foundation cddl/contrib/opensolaris/tools/ctf/common/memory.c | 14 ++++++++++++++ cddl/contrib/opensolaris/tools/ctf/common/memory.h | 1 + cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c | 7 ++++--- 3 files changed, 19 insertions(+), 3 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a853b4c425697a76c61ffa4fbd8bf7da5454807a commit a853b4c425697a76c61ffa4fbd8bf7da5454807a Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2022-08-03 00:32:17 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2022-08-11 14:36:11 +0000 ctfconvert: Give bitfield types names distinct from the base type CTF integers have an explicit width and so can be used to represent bitfields. Bitfield types emitted by ctfconvert(1) share the name of the base integer type, so a struct field with type "unsigned int : 15" will have a type named "unsigned int". To avoid ambiguity when looking up types by name, add a suffix to names of bitfield types to distinguish them from the base type. Then, if ctfmerge happens to order bitfield types before the corresponding base type in a CTF file, a name lookup will return the base type, which is always going to be the desired behaviour. PR: 265403 Reported by: cy Sponsored by: The FreeBSD Foundation (cherry picked from commit 1165fc9a526630487a1feb63daef65c5aee1a583) cddl/contrib/opensolaris/tools/ctf/common/memory.c | 14 ++++++++++++++ cddl/contrib/opensolaris/tools/ctf/common/memory.h | 1 + cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c | 7 ++++--- 3 files changed, 19 insertions(+), 3 deletions(-)