13.09.2015, 23:54, "Mark Johnston" <ma...@freebsd.org>:
> 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?
I did clean buildworld/installworld w/ clean buildkernel and the situation is
really much better now:
I've got only 27633 types, with 493 duplicates, so it is not _that_ close.
(So I suppose that for some reason I got old ctfmerge)
My config for that kernel:
include GENERIC
nomakeoptions DEBUG
makeoptions DEBUG="-O2 -gdwarf-2"
options KTR
options KTR_MASK=(0)
options KDB_TRACE
options KDB_UNATTENDED
options BREAK_TO_DEBUGGER
options ALT_BREAK_TO_DEBUGGER
options MROUTING
>
>> 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"
