From owner-freebsd-stable@FreeBSD.ORG Fri Mar 28 03:03:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB6B7CAF; Fri, 28 Mar 2014 03:03:12 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A1FD53; Fri, 28 Mar 2014 03:03:12 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id lg15so5352943vcb.30 for ; Thu, 27 Mar 2014 20:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GJbQtKKvcO0l1KAnLQ9h/bz+0QdEmua7cSkZgyIn4aw=; b=P/t2MfAyocjmEPvTKVfuUCZ794/4aoVp7BiMBDko9G9XNyLPyQdnxYK7reG5mabF1R mJQIEovdZRtjGh9PUH7WVEE+a8q1O7+a5tW0N8jnlkJTECXzkMGVpwhN3zYs3VAn43wk 93abuQAFlI/giR/yhxYpJi/jOaZvJwXM1FUZyukoqv9IACRdDxCw7OwP1itAabfXOvQJ BPcr2TNax0yYsgR4b3TirBNAu/ZW2BmCzkBUSrg3mxTjg6YmmsrvkcQnQmk2qR1iXMqP B+mpolRB2P77guCpTtDdC7qimAtrfaQMJLTZPU2Bdl3o1oASaU64jzWUw7vGlR/ai4sG j1aQ== MIME-Version: 1.0 X-Received: by 10.58.238.35 with SMTP id vh3mr4744571vec.16.1395975791483; Thu, 27 Mar 2014 20:03:11 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Thu, 27 Mar 2014 20:03:11 -0700 (PDT) In-Reply-To: References: <0E7E81A1-54E9-4920-A360-005A1C0C4D47@FreeBSD.org> <20140327002240.GC49672@raichu> Date: Thu, 27 Mar 2014 23:03:11 -0400 X-Google-Sender-Auth: _EzQfIcp04trAi4TnAsnY7GjXxM Message-ID: Subject: Re: HEADS UP: merged llvm/clang 3.4 From: Mark Johnston To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable stable , Kai Wang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 03:03:13 -0000 On Thu, Mar 27, 2014 at 6:32 PM, Dimitry Andric wrote: > On 27 Mar 2014, at 01:22, Mark Johnston wrote: >> On Fri, Mar 21, 2014 at 07:17:22PM +0100, Dimitry Andric wrote: >>> Hi, >>> >>> I have just merged llvm and clang 3.4 release to stable/10 (r263508) and >>> stable/9 (r263509). This already includes a number of post-3.4 fixes, >>> though there are a few that are still awaiting the MFC timeout (e.g. the >>> updated Sparc64 backend, and some things that were just fixed the day >>> before yesterday). >>> >>> Since the most obvious problems have already been addressed in head, I >>> expect this to be a fairly smooth upgrade. If you run into something >>> strange anyway, please reply to this message (CC'ing the list). >>> >>> -Dimitry >>> >> >> Hello, >> >> DTrace seems to no longer work properly on stable/10; I get errors like >> the following >> >> dtrace: invalid probe specifier pid$target::malloc:entry{ }: >> "/usr/lib/dtrace/io.d", line 49: cannot find type: struct devstat*: Type >> information is in parent and unavailable >> >> and I know of a couple other users running into the same problem. >> >> I recall that some changes to libdwarf, libelf and the CTF tools were needed >> in order to work with clang 3.4; do you know if there's any plan to MFC them >> soon as well? > > I have taken a look, but libdwarf and libelf were reorganized quite a > bit, and it would require library bumps, which are difficult (but > apparently not unheard of) for stable branches. I am also not sure if > the actual workarounds can be successfully ported back to the versions > of libdwarf, libelf and CTF in stable/10 and stable/9. Is there any reason that the newer libdwarf and libelf couldn't coexist alongside libdwarf and libelf in stable/9 and 10? That is, install them to /usr/lib/private or so and have the CTF tools link against them instead of the system libraries. > > In other words, it is going to take a while to fix it. If you really > need DTrace, you can compile your kernel with gcc for now. I'm willing to work on the above if there's consensus that it's an acceptable solution. To my knowledge, 10.0 is the first release where (kernel) DTrace works out of the box; it's rather unfortunate that stable/10 has regressed to a point where DTrace is just completely broken when using the system compiler, especially now that gcc is no longer built by default.