Re: lib/50485: dtrace doesn't work (fails on loading a script, psinfo.d)

[Richard PALO <richard%netbsd.org@localhost>]

The following reply was made to PR lib/50485; it has been noted by GNATS.

From: Richard PALO <richard%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/50485: dtrace doesn't work (fails on loading a script, psinfo.d)
Date: Tue, 02 Aug 2016 18:57:57 +0200

 Le 02/08/16 08:55, Christos Zoulas a écrit :
 >  I think this is acause because of a type table overflow. Try with a non-generic
 >  kernel that only has the drivers you need.
 >  
 >  christos
 >  
 > 
 
 ehhh, is there a simple way to do this... I extracted the drivers loaded 
 via modstat, but it looks a bit tedious to go through one by one.
 
 I started out by commenting out nouveau and intel since I have
 a radeon in my laptop but that really didn't make any difference.
 (I only rebuilt and rebooted a new kernel)
 
 Then I wondered about the types in these driver modules et al.
 
 ctfdump -S on some modules such as compat/compat.kmod or compat_linux/compat_linux.kmod
 or zfs/zfs.kmod, not to mention dtrace_syscall/dtrace_syscall.kmod shows
 a large number of types (these are between 1500..2500)
 
 One thing I don't notice is any uniquifcation being done, 
 e.g. ctfmerge -d ${kernelconf}/netbsd ...
 
 Any particular reason or is this something that could ease problems?
 
 In illumos, for example, there is even an ipctf.a that is created to 
 maximise the number of common types found there too as it is heavily used... 
 
 Perhaps some of these techniques can get over table size issues more easily.
 
 -- 
 Richard PALO