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

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

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.