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
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to