On Sun, Sep 13, 2015 at 04:23:23PM +0300, Alexander V. Chernikov wrote: > Hello all, > > I keep running in > "dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39: > failed to copy type of 'pr_uid': Type information is in parent and > unavailable" > message more and more often while trying to trace different -current kernels. > > Typically the reason besides that is the number of types embedded in kernel > CTF: > ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}' > 37160 > > We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/ > highest bit set) are considered "child" types with the information stored in > "parent"). > ctfmerge ignores this fact and instead of yelling emits type indices above > 32k. On the other hand, libctf sees such indices while parsing sections and > since there is no > "parent" for kernel, it emits the error above and stops. > > Thankfully, r287234 really improved the situation for ctfmerge, but there are > still several thousands of identical structures and the total number is close > to 32k.
r281797 and r287234 should have fixed most instances of duplicate type definitions. At the moment, amd64 GENERIC and GENERIC-NODEBUG have roughly 25K types in their respective CTF containers; there is a small handful of duplicates, but at least some of them are legitimate (some pairs of drivers redefine the same types, e.g. aac(4)/aacraid(4) or mps(4)/mpr(4)). Could you post a config that results in the large number of duplicates you mention above? > > Personally I solved this by removing unneeded devices from GENERIC-inherited > configs. > I wonder, however if this can be handled better. FWIW, removing old drivers from GENERIC would be straightforward if we could auto-load KLDs based on device IDs. > > E.g. either show better error in dtrace(1) or make ctfmerge fail causing > kernel build to stop (since we asked for dtrace but in reality it wouldn't > work), or remove some stale devices from GENERIC, or .something totally > different? One more radical option is to extend the width of CTF type IDs. I've been holding off on doing this for a few reasons: - Doing so would change the binary format, making us incompatible with the reference CTF code in illumos. - Type IDs are embedded in quite a few places in the various CTF structures, so enlarging them from 16 bits to 32 bits will bloat CTF containers somewhat. - I was under the impression that r287234 addressed the problem sufficiently for now. If type ID space is still a problem post-r287234, I think it's time to just go ahead and change the format. But first I'd like to understand the cause of the duplication you're seeing. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"