> Date: Sun, 6 Apr 2025 23:50:37 +0000 > From: Emmanuel Dreyfus <m...@netbsd.org> > > On Sun, Apr 06, 2025 at 03:50:44AM +0000, Taylor R Campbell wrote: > > Try the attached patch? > > I restarted with stock 10.0 XEN3_DOMU kernel to get dtrace working > (it does not), but now the problem seems to have vanished. I run > with two vcpu and timecounter xen_system_time, ntpd syncs without > a hithch. This is a bit frustrating. Perhaps it needs more load > to fail. > > Loading dtrace module fails on this: > kobj_checksyms, 1004: [solaris]: linker error: symbol `sdt_provider_sdt' not > found > WARNING: module error: unable to affix module `solaris', error 8 > WARNING: module error: recursive load failed for `dtrace' (`solaris' > required), error 8 > > I cannot find sdt_provider_sdt anywhere in kernel sources.
Defined in kern_sdt.c by SDT_PROVIDER_DEFINE(sdt); Requires `options KDTRACE_HOOKS' in the kernel you want to load dtrace into. This was only added to amd64/XEN3_DOMU in the netbsd-10 branch a week ago. However, I seem to recall there is a problem where the Xen loader doesn't pass the CTF data to NetBSD, so it's considerably less useful than it should be -- this might be why I held off on requesting pullup myself. The dtrace script I suggested should work but if you try to use anything that requires dtrace to know about types, like printing args[N] rather than argN or reading named structure members, it might not work.
