From owner-freebsd-current@freebsd.org Sun Sep 13 20:54:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B071BA03D71 for ; Sun, 13 Sep 2015 20:54:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83E431CA9; Sun, 13 Sep 2015 20:54:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by padhk3 with SMTP id hk3so122706333pad.3; Sun, 13 Sep 2015 13:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QYLtVL7i0kXyMtfGgBK7NbVGFKsqHmVzIaTMO8ykPAc=; b=kWcDqQgLmHaJkgZOhBblc/Ekcl3YiYfDDqqUqXtmZr35x9WYVA1iCLHH4HHDzs6G7r RCxNFPS39hezwT17vFKgN+TT1T933EmGHzsY0rP58OMMvW5p+DIPFbl1GluTC//Ncz7e C+w5DKKOfPLmH+SIBeDt4ugv2/jnrHh4iCfBQGBu7VcwV8Um99p6EFnCHAebAJpg+oxY FEqRricmb5X8CPurZkt+bOACcuXkgbxz6BeD5LT+UwiAudBgD6IiQKQyvYIkshIzakvk gvbDkFlnHxX3XehMrIWorltXmfoKADnzJZaVcjke4qJ7zObT7nBGkcAdW8i80aoxymWb xyQA== X-Received: by 10.67.12.166 with SMTP id er6mr26199074pad.40.1442177660987; Sun, 13 Sep 2015 13:54:20 -0700 (PDT) Received: from muskytusk ([104.236.250.12]) by smtp.gmail.com with ESMTPSA id lc9sm11909249pbc.52.2015.09.13.13.54.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2015 13:54:19 -0700 (PDT) Sender: Mark Johnston Date: Sun, 13 Sep 2015 20:53:33 +0000 From: Mark Johnston To: "Alexander V. Chernikov" Cc: FreeBSD CURRENT Subject: Re: kernel dtrace and current Message-ID: <20150913205333.GA2444@muskytusk> References: <738721442150603@web6j.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <738721442150603@web6j.yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 20:54:21 -0000 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.