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"
