Re: port-xen/57535 (dtrace on Xen DOMU might need -x nolibs)

[Brad Spencer <brad%anduin.eldar.org@localhost>]

The following reply was made to PR port-xen/57535; it has been noted by GNATS.

From: Brad Spencer <brad%anduin.eldar.org@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-xen-maintainer%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: port-xen/57535 (dtrace on Xen DOMU might need -x nolibs)
Date: Sat, 22 Jul 2023 07:46:28 -0400

 Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
 
 >> Date: Sat, 22 Jul 2023 06:42:27 -0400
 >> From: Brad Spencer <brad%anduin.eldar.org@localhost>
 >> 
 >> I did a clean build of the world after a cvs update of the source tree
 >> and the problem mentioned in this PR is still present:
 >
 > Can you please share the output of:
 >
 > $ ctfdump -t SAMWISE/adiantum.o
 > $ ctfdump -t SAMWISE/netbsd
 > $ config -x SAMWISE/netbsd
 >
 > in your clean build?
 >
 > If you delete the SAMWISE build directory and rebuild it, do you get
 > the same output?
 
 I should not build kernels before breakfast.  No, the build artifact
 directory for that kernel was NOT completely clean and I noticed that
 later.  The rest of the world was completely empty.
 
 After really making sure that the build directory for the custom kernel
 was gone, the build with "-g" worked fine.  Sorry for the
 noise... however, the original problem reported still is present, so
 adding debugging symbols didn't seem to help.
 
 # dtrace -n 'sdt:xen:clock:, sdt:xen:hardclock:, sdt:xen:timecounter: { printf("%d %d %d %d %d %d %d %d", arg0, arg1, arg2, arg3, arg4, arg5, arg6, arg7) }'
 dtrace: invalid probe specifier sdt:xen:clock:, sdt:xen:hardclock:, sdt:xen:timecounter: { printf("%d %d %d %d %d %d %d %d", arg0, arg1, arg2, arg3, arg4, arg5, arg6, arg7) }: "/usr/lib/dtrace/psinfo.d", line 46: syntax error near "u_int"
 
 uname -a
 NetBSD samwise.nat.eldar.org 10.99.6 NetBSD 10.99.6 (SAMWISE) #0: Sat Jul 22 07:14:36 EDT 2023  brad%samwise.nat.eldar.org@localhost:/usr/src/sys/arch/amd64/compile/SAMWISE amd64
 
 I get this on the console of the DOMU when the dtrace is executed:
 
 [   272.554696] fbt: no CTF data for module netbsd
 
 >> I noted that a difference between GENERIC and XEN3_DOM0 is that there is
 >> a 'makeoptions DEBUG="-g"' present with a comment that it is needed for
 >> CTF and this option isn't present in XEN3_DOMU.
 >
 > Evidently I never noticed this because I always build with MKDEBUG=yes
 > (or MKDEBUGKERNEL=yes) which renders it unnecessary.
 >
 > I think maybe we should delete the makeoptions lines in the kernel
 > configs, and set MKDEBUG=yes or at least MKDEBUGKERNEL=yes by default.
 
 Probably, but I don't have a great strong opinion.  It would seem like
 having magic makeoptions for something like this isn't all that
 desirable.  I know that I have personally broken the official build
 because I forgot to test a build with MKDEBUG=yes and missed something
 new that was part of the debug set.  It does add to the size of the
 artifacts and does take longer.  Maybe it should be enabled for -current
 and BETAs and disabled for the releases.