From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 14:36:16 2014 Return-Path: Delivered-To: freebsd-toolchain@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 B21DDF26 for ; Fri, 28 Feb 2014 14:36:16 +0000 (UTC) Received: from smtpout3.timeweb.ru (smtpout3.timeweb.ru [92.53.117.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69C9512A7 for ; Fri, 28 Feb 2014 14:36:16 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WJOXn-0008Ex-77 for freebsd-toolchain@freebsd.org; Fri, 28 Feb 2014 18:36:07 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id CE2687B1 for ; Fri, 28 Feb 2014 18:36:06 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id AD4EA2457; Fri, 28 Feb 2014 18:36:06 +0400 (MSK) Date: Fri, 28 Feb 2014 18:36:06 +0400 From: Dmitry Marakasov To: freebsd-toolchain@freebsd.org Subject: clang (both 3.3 and 3.4) OOM crashes on HEAD Message-ID: <20140228143606.GD29171@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 14:36:16 -0000 Hi! I've been getting some failure mails from pkg building cluster related to clang crashes: http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s/logs/arx-libertatis-1.0.3_2.log http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s/logs/supertuxkart-0.8.1.log At first I thought they'll go away with clang 3.4, but recently I've added HEAD jail to my tinderbox and reproduced these. Also a reason of crashes become apparent: c++ eats all available memoty (15G RSS in my case). I though of investigating these further, but wanted to check if it's already known first. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 14:47:28 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DB041F5 for ; Fri, 28 Feb 2014 14:47:28 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2997A1367 for ; Fri, 28 Feb 2014 14:47:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::83f:465:d505:2ec0] (unknown [IPv6:2001:7b8:3a7:0:83f:465:d505:2ec0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 213BE5C45; Fri, 28 Feb 2014 15:47:17 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C11C60DA-43FA-4622-BE19-80E712A742D4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD From: Dimitry Andric In-Reply-To: <20140228143606.GD29171@hades.panopticon> Date: Fri, 28 Feb 2014 15:47:04 +0100 Message-Id: References: <20140228143606.GD29171@hades.panopticon> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 14:47:28 -0000 --Apple-Mail=_C11C60DA-43FA-4622-BE19-80E712A742D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Feb 2014, at 15:36, Dmitry Marakasov wrote: >=20 > I've been getting some failure mails from pkg building cluster related > to clang crashes: >=20 > = http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s= /logs/arx-libertatis-1.0.3_2.log > = http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s/= logs/supertuxkart-0.8.1.log >=20 > At first I thought they'll go away with clang 3.4, but recently I've > added HEAD jail to my tinderbox and reproduced these. Also a reason > of crashes become apparent: c++ eats all available memoty (15G RSS > in my case). >=20 > I though of investigating these further, but wanted to check if it's > already known first. There are a few known OOM bugs in 3.4, but from the logs it is not immediately apparent if you are hitting those, or if they are new bugs. To be able to figure that out, we need the files mentioned in clang's diagnostic messages, e.g. for arx-libertatis: /tmp/Input-XkKTNq.cpp /tmp/Input-XkKTNq.sh and for supertuxkart: /tmp/engine-11FjEA.cpp /tmp/engine-11FjEA.sh Please put them in a tarball, and upload them somewhere so the bugs can be reproduced without having to clone your entire build environment. -Dimitry --Apple-Mail=_C11C60DA-43FA-4622-BE19-80E712A742D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMQoXAACgkQsF6jCi4glqPAFQCfc6yUIt+orPGknAIHTgMD53/p xtsAoNmv25USnHSbLw99WF3ZMTPBMEz5 =H3u5 -----END PGP SIGNATURE----- --Apple-Mail=_C11C60DA-43FA-4622-BE19-80E712A742D4-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 15:07:01 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F4D46C7 for ; Fri, 28 Feb 2014 15:07:01 +0000 (UTC) Received: from smtpout6.timeweb.ru (smtpout6.timeweb.ru [92.53.117.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 579141564 for ; Fri, 28 Feb 2014 15:07:00 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WJP1W-0006Uz-Ju for freebsd-toolchain@FreeBSD.org; Fri, 28 Feb 2014 19:06:50 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 409517E6 for ; Fri, 28 Feb 2014 19:06:50 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 331EB246A; Fri, 28 Feb 2014 19:06:50 +0400 (MSK) Date: Fri, 28 Feb 2014 19:06:50 +0400 From: Dmitry Marakasov To: freebsd-toolchain@FreeBSD.org Subject: More dangerous UB handling of clang (compared to gcc) Message-ID: <20140228150650.GE29171@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:07:01 -0000 Hi! Another issue I wanted to mention: compared to gcc, clang handles some undefined behaviour cases more dangerously. It has the full right to do so as it's UB, however we may want to take extra steps to find and fix these cases. Example: --- ub.cc begins here --- #include int func1() { std::cerr << "func1()\n"; /* no return */ } void func2() { std::cerr << "NEVER CALLED\n"; } int main() { func1(); return 0; } --- ub.cc ends here --- --- % g++46 -o ub ub.cc && ./ub func1() % g++46 -O2 -o ub ub.cc && ./ub func1() % clang++ -o ub ub.cc && ./ub ub.cc:6:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ 1 warning generated. func1() Illegal instruction % clang++ -O2 -o ub ub.cc && ./ub ub.cc:6:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ 1 warning generated. func1() NEVER CALLED Segmentation fault --- As you can see, while with gcc the function returns even if it has no return statement, with clang it either crashes or calls the following function. This may lead to new crashes and security problems after switching to clang (most likely in ports code of course). I wonder of we could make use of -Werror=return-type which makes the warning issued by clang here fatal, what do you think? If adding it to default CFLAGS/CXXFLAGS is not an option, we may at least have an extra `strict' pkg-fallout builder. Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=18296 (resoleved as INVALID). I'm also positively sure that I've encountered another problematic UB case with another warning, but I don't remember which. Real list of useful Werror's may be quite big. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 15:38:43 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83A8C4A8 for ; Fri, 28 Feb 2014 15:38:43 +0000 (UTC) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 576011836 for ; Fri, 28 Feb 2014 15:38:43 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so898539pbb.36 for ; Fri, 28 Feb 2014 07:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KmuKkCGqZ0Lq/IFb8NW4x2ms0WyNzZnl/BcAld+W1oY=; b=kcKUFbHgS9cwmjnmtm48RDE9lxNKb0MvJZnQW5PSHFfXLvEdBn2TOCxNE0KezBmvXG FliJNkFkcsJgTL4X5kBCzQ65z+AXNCBA3FVHGrDFjPlmo3+Zs8fg4vnhGHrZVOF3TkMM y83JqaWg73sgteyCJPf+UgGl8YBsDs6mvAyzTufGzm3svXWes1onOUcX/CHT9z/R2EDO RZJweB06jYESA2E+SxXRR+uRM1G0gLkQ2iUitMSXraPWQG+H2SJYChxgPMjZdtghVvKQ Orl5tSV/FnOH3BT2QAfO4VfAdO/P+NDefE0yZuT+5Dqz2BVTYjQfKXmNJ0N86jwkcU5p VeWQ== X-Received: by 10.68.212.161 with SMTP id nl1mr4242280pbc.142.1393601922940; Fri, 28 Feb 2014 07:38:42 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ou9sm7281094pbc.30.2014.02.28.07.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:38:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: More dangerous UB handling of clang (compared to gcc) From: Warner Losh In-Reply-To: <20140228150650.GE29171@hades.panopticon> Date: Fri, 28 Feb 2014 08:38:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> References: <20140228150650.GE29171@hades.panopticon> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:38:43 -0000 On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov wrote: > Hi! >=20 > Another issue I wanted to mention: compared to gcc, clang handles > some undefined behaviour cases more dangerously. It has the full > right to do so as it's UB, however we may want to take extra steps > to find and fix these cases. Except this is a flat out bug=E2=80=A6. > Example: >=20 > --- ub.cc begins here --- > #include >=20 > int func1() { > std::cerr << "func1()\n"; > /* no return */ > } >=20 > void func2() { > std::cerr << "NEVER CALLED\n"; > } >=20 > int main() { > func1(); > return 0; > } > --- ub.cc ends here --- >=20 > --- > % g++46 -o ub ub.cc && ./ub > func1() > % g++46 -O2 -o ub ub.cc && ./ub > func1() > % clang++ -o ub ub.cc && ./ub > ub.cc:6:1: warning: control reaches end of non-void function > [-Wreturn-type] > } > ^ > 1 warning generated. > func1() > Illegal instruction > % clang++ -O2 -o ub ub.cc && ./ub > ub.cc:6:1: warning: control reaches end of non-void function > [-Wreturn-type] > } > ^ > 1 warning generated. > func1() > NEVER CALLED > Segmentation fault > --- >=20 > As you can see, while with gcc the function returns even if it has no > return statement, with clang it either crashes or calls the following > function. This may lead to new crashes and security problems after > switching to clang (most likely in ports code of course). This is a flat out bug. When control reaches the end of a function, it = must return, even if there=E2=80=99s no return statement. The value = returned from func1() is, of course, undefined, but this is well defined = behavior in the standard=E2=80=A6 I=E2=80=99d be very interested to see chapter and verse on this one... > I wonder of we could make use of -Werror=3Dreturn-type which makes the > warning issued by clang here fatal, what do you think? If adding it to > default CFLAGS/CXXFLAGS is not an option, we may at least have an > extra `strict' pkg-fallout builder. >=20 > Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=3D18296 = (resoleved > as INVALID). I believe this resolution is, in fact, bogus. Sure, insert ud2, but also = put a f=E2=80=99ing return in there. I know in C11,this id definitely the case: 6.9.1: 12 If the } that terminates a function is reached, and the value of the = function call is used by the caller, the behavior is unde=EF=AC=81ned. But the C++ standard is somewhat opaque on the topic, but none of the 56 = instances of =E2=80=98undefined results=E2=80=99 in the standard = appeared to apply. > I'm also positively sure that I've encountered another problematic > UB case with another warning, but I don't remember which. Real > list of useful Werror's may be quite big. Yea, this is a big deal. Sure, people shouldn=E2=80=99t do this, but = this kind of undefined behavior is well outside the bounds of = traditional compilers. Warner From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 15:43:35 2014 Return-Path: Delivered-To: freebsd-toolchain@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 4AEDA58F; Fri, 28 Feb 2014 15:43:35 +0000 (UTC) Received: from smtpout6.timeweb.ru (smtpout6.timeweb.ru [92.53.117.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F36CD18B7; Fri, 28 Feb 2014 15:43:34 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WJPb0-0007NP-5F; Fri, 28 Feb 2014 19:43:30 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id BEFE381B; Fri, 28 Feb 2014 19:43:29 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 8259B2B36; Fri, 28 Feb 2014 19:43:28 +0400 (MSK) Date: Fri, 28 Feb 2014 19:43:28 +0400 From: Dmitry Marakasov To: Dimitry Andric Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD Message-ID: <20140228154328.GA13454@hades.panopticon> References: <20140228143606.GD29171@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:43:35 -0000 * Dimitry Andric (dim@FreeBSD.org) wrote: > > I've been getting some failure mails from pkg building cluster related > > to clang crashes: > > > > http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s/logs/arx-libertatis-1.0.3_2.log > > http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s/logs/supertuxkart-0.8.1.log > > > > At first I thought they'll go away with clang 3.4, but recently I've > > added HEAD jail to my tinderbox and reproduced these. Also a reason > > of crashes become apparent: c++ eats all available memoty (15G RSS > > in my case). > > > > I though of investigating these further, but wanted to check if it's > > already known first. > > There are a few known OOM bugs in 3.4, but from the logs it is not > immediately apparent if you are hitting those, or if they are new bugs. Note that it affects both 3.3 and 3.4. I think it was triggered by something unrelated to clang update, maybe libc++ update. > To be able to figure that out, we need the files mentioned in clang's > diagnostic messages, e.g. for arx-libertatis: > > /tmp/Input-XkKTNq.cpp > /tmp/Input-XkKTNq.sh Here's one from arx-libertatis: http://people.freebsd.org/~amdmi3/clang-eats-mem-bug.tar.bz2 The bug is reproducible on my 10.x with both system clang 3.3 (after removing -vectorize-loops -vectorize-slp options) and with clang 3.4 from ports. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 1 23:19:51 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C47C17B for ; Sat, 1 Mar 2014 23:19:51 +0000 (UTC) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by mx1.freebsd.org (Postfix) with ESMTP id 6889D1B2A for ; Sat, 1 Mar 2014 23:19:51 +0000 (UTC) Received: from BLU182-W84 ([65.55.111.136]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Mar 2014 15:18:45 -0800 X-TMN: [MtACAk17RaCiU+3e15+a+96mzGp/cpP/] X-Originating-Email: [acharles@outlook.com] Message-ID: From: Ahmed Charles To: Warner Losh , Dmitry Marakasov Subject: RE: More dangerous UB handling of clang (compared to gcc) Date: Sat, 1 Mar 2014 15:18:44 -0800 Importance: Normal In-Reply-To: <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> References: <20140228150650.GE29171@hades.panopticon>, <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2014 23:18:45.0801 (UTC) FILETIME=[97FEF190:01CF35A4] Cc: "freebsd-toolchain@FreeBSD.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 23:19:51 -0000 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFN1YmplY3Q6IFJlOiBN b3JlIGRhbmdlcm91cyBVQiBoYW5kbGluZyBvZiBjbGFuZyAoY29tcGFyZWQgdG8gZ2NjKQo+IEZy b206IGJzZGltcEBnbWFpbC5jb20KPiBEYXRlOiBGcmksIDI4IEZlYiAyMDE0IDA4OjM4OjM4IC0w NzAwCj4gVG86IGFtZG1pM0BhbWRtaTMucnUKPiBDQzogZnJlZWJzZC10b29sY2hhaW5ARnJlZUJT RC5vcmcKPgo+Cj4gT24gRmViIDI4LCAyMDE0LCBhdCA4OjA2IEFNLCBEbWl0cnkgTWFyYWthc292 IDxhbWRtaTNAYW1kbWkzLnJ1PiB3cm90ZToKPgo+PiBIaSEKPj4KPj4gQW5vdGhlciBpc3N1ZSBJ IHdhbnRlZCB0byBtZW50aW9uOiBjb21wYXJlZCB0byBnY2MsIGNsYW5nIGhhbmRsZXMKPj4gc29t ZSB1bmRlZmluZWQgYmVoYXZpb3VyIGNhc2VzIG1vcmUgZGFuZ2Vyb3VzbHkuIEl0IGhhcyB0aGUg ZnVsbAo+PiByaWdodCB0byBkbyBzbyBhcyBpdCdzIFVCLCBob3dldmVyIHdlIG1heSB3YW50IHRv IHRha2UgZXh0cmEgc3RlcHMKPj4gdG8gZmluZCBhbmQgZml4IHRoZXNlIGNhc2VzLgo+Cj4gRXhj ZXB0IHRoaXMgaXMgYSBmbGF0IG91dCBidWfigKYuCj4KPj4gRXhhbXBsZToKPj4KPj4gLS0tIHVi LmNjIGJlZ2lucyBoZXJlIC0tLQo+PiAjaW5jbHVkZSA8aW9zdHJlYW0+Cj4+Cj4+IGludCBmdW5j MSgpIHsKPj4gc3RkOjpjZXJyIDw8ICJmdW5jMSgpXG4iOwo+PiAvKiBubyByZXR1cm4gKi8KPj4g fQo+Pgo+PiB2b2lkIGZ1bmMyKCkgewo+PiBzdGQ6OmNlcnIgPDwgIk5FVkVSIENBTExFRFxuIjsK Pj4gfQo+Pgo+PiBpbnQgbWFpbigpIHsKPj4gZnVuYzEoKTsKPj4gcmV0dXJuIDA7Cj4+IH0KPj4g LS0tIHViLmNjIGVuZHMgaGVyZSAtLS0KPj4KPj4gLS0tCj4+ICUgZysrNDYgLW8gdWIgdWIuY2Mg JiYgLi91Ygo+PiBmdW5jMSgpCj4+ICUgZysrNDYgLU8yIC1vIHViIHViLmNjICYmIC4vdWIKPj4g ZnVuYzEoKQo+PiAlIGNsYW5nKysgLW8gdWIgdWIuY2MgJiYgLi91Ygo+PiB1Yi5jYzo2OjE6IHdh cm5pbmc6IGNvbnRyb2wgcmVhY2hlcyBlbmQgb2Ygbm9uLXZvaWQgZnVuY3Rpb24KPj4gWy1XcmV0 dXJuLXR5cGVdCj4+IH0KPj4gXgo+PiAxIHdhcm5pbmcgZ2VuZXJhdGVkLgo+PiBmdW5jMSgpCj4+ IElsbGVnYWwgaW5zdHJ1Y3Rpb24KPj4gJSBjbGFuZysrIC1PMiAtbyB1YiB1Yi5jYyAmJiAuL3Vi Cj4+IHViLmNjOjY6MTogd2FybmluZzogY29udHJvbCByZWFjaGVzIGVuZCBvZiBub24tdm9pZCBm dW5jdGlvbgo+PiBbLVdyZXR1cm4tdHlwZV0KPj4gfQo+PiBeCj4+IDEgd2FybmluZyBnZW5lcmF0 ZWQuCj4+IGZ1bmMxKCkKPj4gTkVWRVIgQ0FMTEVECj4+IFNlZ21lbnRhdGlvbiBmYXVsdAo+PiAt LS0KPj4KPj4gQXMgeW91IGNhbiBzZWUsIHdoaWxlIHdpdGggZ2NjIHRoZSBmdW5jdGlvbiByZXR1 cm5zIGV2ZW4gaWYgaXQgaGFzIG5vCj4+IHJldHVybiBzdGF0ZW1lbnQsIHdpdGggY2xhbmcgaXQg ZWl0aGVyIGNyYXNoZXMgb3IgY2FsbHMgdGhlIGZvbGxvd2luZwo+PiBmdW5jdGlvbi4gVGhpcyBt YXkgbGVhZCB0byBuZXcgY3Jhc2hlcyBhbmQgc2VjdXJpdHkgcHJvYmxlbXMgYWZ0ZXIKPj4gc3dp dGNoaW5nIHRvIGNsYW5nIChtb3N0IGxpa2VseSBpbiBwb3J0cyBjb2RlIG9mIGNvdXJzZSkuCj4K PiBUaGlzIGlzIGEgZmxhdCBvdXQgYnVnLiBXaGVuIGNvbnRyb2wgcmVhY2hlcyB0aGUgZW5kIG9m IGEgZnVuY3Rpb24sIGl0IG11c3QgcmV0dXJuLCBldmVuIGlmIHRoZXJl4oCZcyBubyByZXR1cm4g c3RhdGVtZW50LiBUaGUgdmFsdWUgcmV0dXJuZWQgZnJvbSBmdW5jMSgpIGlzLCBvZiBjb3Vyc2Us IHVuZGVmaW5lZCwgYnV0IHRoaXMgaXMgd2VsbCBkZWZpbmVkIGJlaGF2aW9yIGluIHRoZSBzdGFu ZGFyZOKApgo+Cj4gSeKAmWQgYmUgdmVyeSBpbnRlcmVzdGVkIHRvIHNlZSBjaGFwdGVyIGFuZCB2 ZXJzZSBvbiB0aGlzIG9uZS4uLgoKbjM2OTA6IDYuNi4zW3N0bXQucmV0dXJuXS9wMgoKRmxvd2lu ZyBvZmYgdGhlIGVuZCBvZiBhIGZ1bmN0aW9uIGlzIGVxdWl2YWxlbnQgdG8gYSByZXR1cm4gd2l0 aCBubyB2YWx1ZTsgdGhpcyByZXN1bHRzIGluIHVuZGVmaW5lZCBiZWhhdmlvciBpbiBhIHZhbHVl LXJldHVybmluZyBmdW5jdGlvbi4KCkMrKyBhbmQgQyBhcmUgZGlzdGluY3RseSBkaWZmZXJlbnQg aW4gdGhpcyByZWdhcmQuCgo+PiBJIHdvbmRlciBvZiB3ZSBjb3VsZCBtYWtlIHVzZSBvZiAtV2Vy cm9yPXJldHVybi10eXBlIHdoaWNoIG1ha2VzIHRoZQo+PiB3YXJuaW5nIGlzc3VlZCBieSBjbGFu ZyBoZXJlIGZhdGFsLCB3aGF0IGRvIHlvdSB0aGluaz8gSWYgYWRkaW5nIGl0IHRvCj4+IGRlZmF1 bHQgQ0ZMQUdTL0NYWEZMQUdTIGlzIG5vdCBhbiBvcHRpb24sIHdlIG1heSBhdCBsZWFzdCBoYXZl IGFuCj4+IGV4dHJhIGBzdHJpY3QnIHBrZy1mYWxsb3V0IGJ1aWxkZXIuCj4+Cj4+IFJlbGF0ZWQg Y2xhbmcgYnVnOiBodHRwOi8vbGx2bS5vcmcvYnVncy9zaG93X2J1Zy5jZ2k/aWQ9MTgyOTYgKHJl c29sZXZlZAo+PiBhcyBJTlZBTElEKS4KPgo+IEkgYmVsaWV2ZSB0aGlzIHJlc29sdXRpb24gaXMs IGluIGZhY3QsIGJvZ3VzLiBTdXJlLCBpbnNlcnQgdWQyLCBidXQgYWxzbyBwdXQgYSBm4oCZaW5n IHJldHVybiBpbiB0aGVyZS4KPgo+IEkga25vdyBpbiBDMTEsdGhpcyBpZCBkZWZpbml0ZWx5IHRo ZSBjYXNlOgo+Cj4gNi45LjE6Cj4gMTIgSWYgdGhlIH0gdGhhdCB0ZXJtaW5hdGVzIGEgZnVuY3Rp b24gaXMgcmVhY2hlZCwgYW5kIHRoZSB2YWx1ZSBvZiB0aGUgZnVuY3Rpb24gY2FsbCBpcyB1c2Vk IGJ5Cj4gdGhlIGNhbGxlciwgdGhlIGJlaGF2aW9yIGlzIHVuZGXvrIFuZWQuCj4KPiBCdXQgdGhl IEMrKyBzdGFuZGFyZCBpcyBzb21ld2hhdCBvcGFxdWUgb24gdGhlIHRvcGljLCBidXQgbm9uZSBv ZiB0aGUgNTYgaW5zdGFuY2VzIG9mIOKAmHVuZGVmaW5lZCByZXN1bHRz4oCZIGluIHRoZSBzdGFu ZGFyZCBhcHBlYXJlZCB0byBhcHBseS4KPgo+PiBJJ20gYWxzbyBwb3NpdGl2ZWx5IHN1cmUgdGhh dCBJJ3ZlIGVuY291bnRlcmVkIGFub3RoZXIgcHJvYmxlbWF0aWMKPj4gVUIgY2FzZSB3aXRoIGFu b3RoZXIgd2FybmluZywgYnV0IEkgZG9uJ3QgcmVtZW1iZXIgd2hpY2guIFJlYWwKPj4gbGlzdCBv ZiB1c2VmdWwgV2Vycm9yJ3MgbWF5IGJlIHF1aXRlIGJpZy4KPgo+IFllYSwgdGhpcyBpcyBhIGJp ZyBkZWFsLiBTdXJlLCBwZW9wbGUgc2hvdWxkbuKAmXQgZG8gdGhpcywgYnV0IHRoaXMga2luZCBv ZiB1bmRlZmluZWQgYmVoYXZpb3IgaXMgd2VsbCBvdXRzaWRlIHRoZSBib3VuZHMgb2YgdHJhZGl0 aW9uYWwgY29tcGlsZXJzLgo+Cj4gV2FybmVyCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4gZnJlZWJzZC10b29sY2hhaW5AZnJlZWJzZC5vcmcg bWFpbGluZyBsaXN0Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8v ZnJlZWJzZC10b29sY2hhaW4KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJl ZWJzZC10b29sY2hhaW4tdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciIAkJIAkgICAJCSAg From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 2 13:26:21 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12000B08; Sun, 2 Mar 2014 13:26:21 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92DB61139; Sun, 2 Mar 2014 13:26:20 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::102d:ec60:fc74:8c90] (unknown [IPv6:2001:7b8:3a7:0:102d:ec60:fc74:8c90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 67B0F5C45; Sun, 2 Mar 2014 14:16:47 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_CA67A0B3-1E8D-4622-BEA0-5F9531396F47"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ctfconvert broken for C++ objects? From: Dimitry Andric In-Reply-To: <81C07491-7E51-4CF0-B257-88ED998EE2A0@FreeBSD.org> Date: Sun, 2 Mar 2014 14:16:40 +0100 Message-Id: References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> <20140220172608.GA85526@freebsd.org> <81C07491-7E51-4CF0-B257-88ED998EE2A0@FreeBSD.org> To: "Justin T. Gibbs" X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 13:26:21 -0000 --Apple-Mail=_CA67A0B3-1E8D-4622-BEA0-5F9531396F47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Feb 2014, at 23:47, Justin T. Gibbs wrote: > On Feb 20, 2014, at 10:26 AM, Roman Divacky = wrote: >=20 >> The dwarf backend for ctfconvert was completely reimplemented a few = weeks ago. >> It's now based on elftoolchain libdwarf. >>=20 >> Test on current. >=20 > The failures I=92ve experienced occur when attempting to ctfconvert = the C++ code in the base (e.g. ATF or devd). You can replicate the = failures on head by applying the share/mk patch below (a version of my = previous patch rebased on head). I've just tried your patch, building devd, and it seemed to have worked just fine (though I had to use DEBUG_FLAGS=3D-g, otherwise ctfconvert would complain there was no type data to convert): $ make WITH_CTF=3Dx DEBUG_FLAGS=3D-g c++ -O2 -pipe -I. -I/usr/src/sbin/devd -g -Qunused-arguments = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -g -Wno-c++11-extensions -c = /usr/src/sbin/devd/devd.cc cc -O2 -pipe -I. -I/usr/src/sbin/devd -g -std=3Dgnu99 = -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c = token.c ctfconvert -L VERSION -g token.o cc -O2 -pipe -I. -I/usr/src/sbin/devd -g -std=3Dgnu99 = -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c = parse.c ctfconvert -L VERSION -g parse.o c++ -O2 -pipe -I. -I/usr/src/sbin/devd -g -Qunused-arguments = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -g -Wno-c++11-extensions = -static -o devd devd.o token.o parse.o -ll -lutil ctfmerge -L VERSION -g -o devd devd.o token.o parse.o gzip -cn /usr/src/sbin/devd/devd.8 > devd.8.gz gzip -cn /usr/src/sbin/devd/devd.conf.5 > devd.conf.5.gz $ ctfdump -S /usr/obj/usr/src/sbin/devd/devd - CTF Statistics = ------------------------------------------------------------- total number of data objects =3D 627 total number of functions =3D 31 total number of function arguments =3D 25 maximum argument list length =3D 2 average argument list length =3D 0.81 total number of types =3D 97 total number of integers =3D 9 total number of floats =3D 0 total number of pointers =3D 24 total number of arrays =3D 16 total number of func types =3D 6 total number of structs =3D 7 total number of unions =3D 2 total number of enums =3D 0 total number of forward tags =3D 4 total number of typedefs =3D 25 total number of volatile types =3D 0 total number of const types =3D 4 total number of restrict types =3D 0 total number of unknowns (holes) =3D 0 total number of struct members =3D 64 maximum number of struct members =3D 25 total size of all structs =3D 3492 maximum size of a struct =3D 3156 average number of struct members =3D 9.14 average size of a struct =3D 498.86 total number of union members =3D 6 maximum number of union members =3D 4 total size of all unions =3D 132 maximum size of a union =3D 128 average number of union members =3D 3.00 average size of a union =3D 66.00 total number of enum members =3D 0 maximum number of enum members =3D 0 total number of unique strings =3D 112 bytes of string data =3D 1051 maximum string length =3D 26 average string length =3D 9.38 > On a slightly related node, do you know why there is a FreeBSD version = ranged exclusion around bootstrapping the dtrace tools? >=20 > =46rom src/Makefile.inc1: > # dtrace tools are required for older bootstrap env and cross-build = =20 > .if ${MK_CDDL} !=3D "no" && \ = =20 > ((${BOOTSTRAPPING} < 1000034 && \ = =20 > !(${BOOTSTRAPPING} >=3D 901505 && ${BOOTSTRAPPING} < 999999)) = \ =20 > || (${MACHINE} !=3D ${TARGET} || ${MACHINE_ARCH} !=3D = ${TARGET_ARCH})) =20 > _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \ = =20 > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge = =20 > .endif This was last changed by Brooks in r251689: "Be more agressive about bootstrapping ctfmerge and ctfconvert so builds from existing releases have a chance of working properly". The range check was modified from: ((${BOOTSTRAPPING} < 800038 && !(${BOOTSTRAPPING} >=3D 700112 && = ${BOOTSTRAPPING} < 799999)) to: ((${BOOTSTRAPPING} < 1000034 && !(${BOOTSTRAPPING} >=3D 901505 && = ${BOOTSTRAPPING} < 999999)) but maybe the 9.x range check is now too narrow? -Dimitry --Apple-Mail=_CA67A0B3-1E8D-4622-BEA0-5F9531396F47 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMTLzwACgkQsF6jCi4glqOr8gCgne9nXvswgZZZexix7Vy/flYn O2oAoJ1WebZhoDeHna8a+QkYkqFIbKGF =7shc -----END PGP SIGNATURE----- --Apple-Mail=_CA67A0B3-1E8D-4622-BEA0-5F9531396F47-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 2 16:31:32 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72DFF5EF for ; Sun, 2 Mar 2014 16:31:32 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32975116D for ; Sun, 2 Mar 2014 16:31:31 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id y20so2503977ier.27 for ; Sun, 02 Mar 2014 08:31:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gFgCVJCzmFUe3rdlJ4D5AtcZ480TTGHyI1ZUwqKUoN8=; b=DJXjJ0JWun5ZUcqh9ww2GBdk9cloJBPKhQs4T8JFM7x7Q3m56zc0CArK8bFL33g3lM D54iigualRRe+cgu5DjR5crnw/t3nEKnHFYoXWfSR955gEVn60HHIUGIYmPBdbAIbZ1x mtDtIEaOiajK4HmI2OoLAjBFZoKiqZ7Jc1MQS4BekWEIfc2G2C3e2Cr+EA4L2PXUT/In 7OW5KQRTvGY/Hjrexwo0oYDBJkFCGpNgSMsmY3SOYMFdhYMtyccAfr1kTo/QEHqF+8Q+ nUuCjg1nSMHVKa1GXoGiKB20fhOFaPAE9JuUQDXqp4v6Q+8yvmJO0pqqRRRl7NefByqf OW1g== X-Gm-Message-State: ALoCoQmMhGQZTldX1dCVlhON3Qci0TWOrx8b85NW62aXpJTq1mwkq2NxftqW7ZDUe5cCyzG7qWMG X-Received: by 10.50.43.228 with SMTP id z4mr17116701igl.10.1393777516026; Sun, 02 Mar 2014 08:25:16 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id mi2sm29951879igb.3.2014.03.02.08.25.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 08:25:15 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: More dangerous UB handling of clang (compared to gcc) From: Warner Losh In-Reply-To: Date: Sun, 2 Mar 2014 09:25:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC02993-ADCF-4403-BA0F-61DBEDDB2116@gmail.com> References: <20140228150650.GE29171@hades.panopticon>, <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> To: Ahmed Charles X-Mailer: Apple Mail (2.1874) Cc: "freebsd-toolchain@FreeBSD.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:31:32 -0000 On Mar 1, 2014, at 4:18 PM, Ahmed Charles wrote: > ---------------------------------------- >> Subject: Re: More dangerous UB handling of clang (compared to gcc) >> From: bsdimp@gmail.com >> Date: Fri, 28 Feb 2014 08:38:38 -0700 >> To: amdmi3@amdmi3.ru >> CC: freebsd-toolchain@FreeBSD.org >>=20 >>=20 >> On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov = wrote: >>=20 >>> Hi! >>>=20 >>> Another issue I wanted to mention: compared to gcc, clang handles >>> some undefined behaviour cases more dangerously. It has the full >>> right to do so as it's UB, however we may want to take extra steps >>> to find and fix these cases. >>=20 >> Except this is a flat out bug=E2=80=A6. >>=20 >>> Example: >>>=20 >>> --- ub.cc begins here --- >>> #include >>>=20 >>> int func1() { >>> std::cerr << "func1()\n"; >>> /* no return */ >>> } >>>=20 >>> void func2() { >>> std::cerr << "NEVER CALLED\n"; >>> } >>>=20 >>> int main() { >>> func1(); >>> return 0; >>> } >>> --- ub.cc ends here --- >>>=20 >>> --- >>> % g++46 -o ub ub.cc && ./ub >>> func1() >>> % g++46 -O2 -o ub ub.cc && ./ub >>> func1() >>> % clang++ -o ub ub.cc && ./ub >>> ub.cc:6:1: warning: control reaches end of non-void function >>> [-Wreturn-type] >>> } >>> ^ >>> 1 warning generated. >>> func1() >>> Illegal instruction >>> % clang++ -O2 -o ub ub.cc && ./ub >>> ub.cc:6:1: warning: control reaches end of non-void function >>> [-Wreturn-type] >>> } >>> ^ >>> 1 warning generated. >>> func1() >>> NEVER CALLED >>> Segmentation fault >>> --- >>>=20 >>> As you can see, while with gcc the function returns even if it has = no >>> return statement, with clang it either crashes or calls the = following >>> function. This may lead to new crashes and security problems after >>> switching to clang (most likely in ports code of course). >>=20 >> This is a flat out bug. When control reaches the end of a function, = it must return, even if there=E2=80=99s no return statement. The value = returned from func1() is, of course, undefined, but this is well defined = behavior in the standard=E2=80=A6 >>=20 >> I=E2=80=99d be very interested to see chapter and verse on this = one... >=20 > n3690: 6.6.3[stmt.return]/p2 >=20 > Flowing off the end of a function is equivalent to a return with no = value; this results in undefined behavior in a value-returning function. >=20 > C++ and C are distinctly different in this regard. Seems like the =E2=80=98jump into the next function=E2=80=99 as a result = of the core dump you put in being optimized away is a breathtakingly = stupid, but allowed, undefined behavior. I mean, as stupid as forking = rogue when #pragma is encountered. Better for that forced core dump to = not be optimized away, or there be a return statement. Hence my belief that the resolution is bogus. >>> I wonder of we could make use of -Werror=3Dreturn-type which makes = the >>> warning issued by clang here fatal, what do you think? If adding it = to >>> default CFLAGS/CXXFLAGS is not an option, we may at least have an >>> extra `strict' pkg-fallout builder. >>>=20 >>> Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=3D18296 = (resoleved >>> as INVALID). >>=20 >> I believe this resolution is, in fact, bogus. Sure, insert ud2, but = also put a f=E2=80=99ing return in there. >>=20 >> I know in C11,this id definitely the case: >>=20 >> 6.9.1: >> 12 If the } that terminates a function is reached, and the value of = the function call is used by >> the caller, the behavior is unde=EF=AC=81ned. >>=20 >> But the C++ standard is somewhat opaque on the topic, but none of the = 56 instances of =E2=80=98undefined results=E2=80=99 in the standard = appeared to apply. >>=20 >>> I'm also positively sure that I've encountered another problematic >>> UB case with another warning, but I don't remember which. Real >>> list of useful Werror's may be quite big. >>=20 >> Yea, this is a big deal. Sure, people shouldn=E2=80=99t do this, but = this kind of undefined behavior is well outside the bounds of = traditional compilers. >>=20 >> Warner >>=20 >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" = =20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 2 17:55:20 2014 Return-Path: Delivered-To: freebsd-toolchain@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 583AD9D6; Sun, 2 Mar 2014 17:55:20 +0000 (UTC) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B5D51813; Sun, 2 Mar 2014 17:55:19 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s22HtIOw001145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Mar 2014 10:55:19 -0700 (MST) (envelope-from gibbs@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ctfconvert broken for C++ objects? From: "Justin T. Gibbs" In-Reply-To: Date: Sun, 2 Mar 2014 10:55:20 -0700 Message-Id: References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> <20140220172608.GA85526@freebsd.org> <81C07491-7E51-4CF0-B257-88ED998EE2A0@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 17:55:20 -0000 --Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 2, 2014, at 6:16 AM, Dimitry Andric wrote: > On 21 Feb 2014, at 23:47, Justin T. Gibbs wrote: >> On Feb 20, 2014, at 10:26 AM, Roman Divacky = wrote: >>=20 >>> The dwarf backend for ctfconvert was completely reimplemented a few = weeks ago. >>> It's now based on elftoolchain libdwarf. >>>=20 >>> Test on current. >>=20 >> The failures I=92ve experienced occur when attempting to ctfconvert = the C++ code in the base (e.g. ATF or devd). You can replicate the = failures on head by applying the share/mk patch below (a version of my = previous patch rebased on head). >=20 > I've just tried your patch, building devd, and it seemed to have = worked > just fine (though I had to use DEBUG_FLAGS=3D-g, otherwise ctfconvert > would complain there was no type data to convert): My buildworld currently dies with the ATF library: --- lib/atf__L --- = =20 --- fs.So --- = =20 ctfconvert -L VERSION -g fs.So = =20 --- process.So --- = =20 ctfconvert -L VERSION -g process.So = =20 --- lib/libutil__L --- = =20 ctfconvert -L VERSION -g property.o = =20 --- lib/atf__L --- = =20 --- fs.So --- = =20 Segmentation fault = =20 *** [fs.So] Error code 139 Can you build all of world with my patch? > This was last changed by Brooks in r251689: "Be more agressive about > bootstrapping ctfmerge and ctfconvert so builds from existing releases > have a chance of working properly". The range check was modified = from: >=20 > ((${BOOTSTRAPPING} < 800038 && !(${BOOTSTRAPPING} >=3D 700112 && = ${BOOTSTRAPPING} < 799999)) >=20 > to: >=20 > ((${BOOTSTRAPPING} < 1000034 && !(${BOOTSTRAPPING} >=3D 901505 && = ${BOOTSTRAPPING} < 999999)) >=20 > but maybe the 9.x range check is now too narrow? Why don=92t we always bootstrap the ctf toolchain when WITH_CTF is = defined? How else would a user migrate from an old tree to a new which = enables newly supported features of ctf (e.g. its use on C++ programs) = that require the new tools? =97 Justin --Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTE3CIAAoJED9n8CuvaSf4Xk8H/jk5m2fEkmmbFghQ3Sk/xDat FtQ9tosQ1siFLvxyJEBnJQ892vKsmi+pcUtPDlRY50G+I9n2k2kOjqwh9dtpNoT1 Ygfu5KR/uViHetLqLZREfh3wGIR9n+m9uKmH/GbmQ7XmaOJwm+xlp24Yd4brgY38 /ioLknu+qjFdgQPPVrWZlWrF+3/yPepKaVVqWGMhLGsggx+qDStgeQHIPhTg6zh9 wjfZd3k4K2FjbRAbF1sw3kIN1n0dQ86fl2cg4JEeWCxqKOF5qlgC2XRepyxV+89+ 4p9I/11XvgNG8EDlVc6cBKjpQ47df6HyKH4gdcjWP/EgHu9qPywDLTO8eAlHeDg= =tBY0 -----END PGP SIGNATURE----- --Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 5 11:30:37 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EF59302; Wed, 5 Mar 2014 11:30:37 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62B83C93; Wed, 5 Mar 2014 11:30:37 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WLA1y-000IXZ-5o; Wed, 05 Mar 2014 12:30:36 +0100 Message-ID: <53170AD1.4090506@FreeBSD.org> Date: Wed, 05 Mar 2014 12:30:25 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Subject: Various issues with Clang and libc++ while playing with OpenCL (FYI) X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QDV5WFf1Xs5Qkq47TOCi0qhIRjdPHel1u" Cc: Koop Mast X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:30:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QDV5WFf1Xs5Qkq47TOCi0qhIRjdPHel1u Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello! [Note: I'm not subscribed to this list] I'm trying to make OpenCL work on FreeBSD, using Mesa 10.1 release candidate. The implementation of libOpenCL.so in Mesa, called Clover, is in C++. In the configure.ac script, they require GCC 4.7+, but I think it's mainly for C++11 support. When building Mesa with Clang 3.4 and 11-CURRENT's libc++, I had the following issues: 1. Clang 3.4 fails to build Clover, see this PR: https://bugs.freedesktop.org/show_bug.cgi?id=3D74098 In the last comment, there's a patch to Clover, working around the problem. Its author opened a ticket on LLVM bug tracker: http://llvm.org/bugs/show_bug.cgi?id=3D18645 2. Mesa's configure script is looking for stddef.h here: /usr/local/llvm34/lib/clang/3.4/include LLVM/Clang ports don't install this file. I just added a symlink to /usr/include/stddef.h and Mesa was happy. I still need to check how it goes if I remove the check and the symlink. But perhaps Mesa is right to expect this header (and maybe other) in this directory, I don't know. 3. Our base libc++ has a bug in the header. I posted a PR on Mesa bug tracker here, before I found out it was a problem with libc++: https://bugs.freedesktop.org/show_bug.cgi?id=3D75505 Apparently, it's fixed in libc++ upstream, in r199848. 4. At runtime, any OpenCL program segfaults in libc++ (I don't have the stack trace at hand and can't remember what it was... Something with basic_string). When using libc++ from ports (devel/libc++, r200683) and the work around for problem #1, Clover builds and OpenCL programs run fine. This is mostly a "FYI" report, I think we can live with libc++ from ports for Mesa. --=20 Jean-S=E9bastien P=E9dron --QDV5WFf1Xs5Qkq47TOCi0qhIRjdPHel1u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTFwrZAAoJEDnpl2Gl/ZTMNEQP/iPjLUvmvma+BeGvOWwsL7Oj UnrjUNTYVQ9QTuFdzUONJxRVEwlcx0rUejHWKZEe7sgHZjJlawITs6kVJNA0cEz3 r5gKfib2GCH5Mc0YUDEsIEEDJs5vbFCE6aONYZ3X5SK5vDRap7H86X/4PKR4K8p/ +plrHWLtovITGvn83sOlzu6zyPZfhEOJuze/vdgJYu0JhXdkoUqyP4ZCqSjHltDd rD3E3rDXWDKfJ97NY9WAH8/chZb8XntCSCdfApl6Vocy9vJFkzHCfnIJpJjF5cSx P/20C55Zxmix41Ls5NycWbtLjJ7FSoOV+dM0sBaAHe545dXZhEjF32oIQUUmQqRZ wNVlZY6GWCVBf6+fmhrkuXgAzmm3cMdj9pRgBXTmEoFG7VerulQ6uEQTwbQakU83 47MMHiQEscXo3Lhxxwqxz3MpTsDUWN7rUxZtDx//akpgGDvktP2ytuD0wCZF9+ol cELlr9E1+m13b2DObSq4qwT7j6v+nCb3eLrYokwEZACFKnzWa8thlOOYrks/efT+ GxIEsVpEnVoD4XbtVG6aK9NYUiIjNO2rVQWNsAnMMwQr69Nt1gWxI0R1fljmxEj3 k0mAUZiDjk2qy2Vb29ueoIkDJ55rIH01EhCXBlVUke8/xJ6D4q2yb5nQrfmMd4rU 8UJCKh+Q6WvOGyth1Jo4 =IbRs -----END PGP SIGNATURE----- --QDV5WFf1Xs5Qkq47TOCi0qhIRjdPHel1u-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 5 20:28:38 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A063EF65; Wed, 5 Mar 2014 20:28:38 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EF32A54; Wed, 5 Mar 2014 20:28:37 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::a4c2:18df:61c3:7c81] (unknown [IPv6:2001:7b8:3a7:0:a4c2:18df:61c3:7c81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8937A5C45; Wed, 5 Mar 2014 21:28:28 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_B8682D86-F6FD-4433-8302-FA7C92A2A179"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Various issues with Clang and libc++ while playing with OpenCL (FYI) From: Dimitry Andric In-Reply-To: <53170AD1.4090506@FreeBSD.org> Date: Wed, 5 Mar 2014 21:28:16 +0100 Message-Id: <08932FE2-8FB5-4EAA-A673-07A3A54721C0@FreeBSD.org> References: <53170AD1.4090506@FreeBSD.org> To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= X-Mailer: Apple Mail (2.1874) Cc: Koop Mast , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:28:38 -0000 --Apple-Mail=_B8682D86-F6FD-4433-8302-FA7C92A2A179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 05 Mar 2014, at 12:30, Jean-S=E9bastien P=E9dron = wrote: > I'm trying to make OpenCL work on FreeBSD, using Mesa 10.1 release > candidate. Very nice to hear! > The implementation of libOpenCL.so in Mesa, called Clover, is in C++. = In > the configure.ac script, they require GCC 4.7+, but I think it's = mainly > for C++11 support. When building Mesa with Clang 3.4 and 11-CURRENT's > libc++, I had the following issues: >=20 > 1. Clang 3.4 fails to build Clover, see this PR: > https://bugs.freedesktop.org/show_bug.cgi?id=3D74098 >=20 > In the last comment, there's a patch to Clover, working around the > problem. Its author opened a ticket on LLVM bug tracker: > http://llvm.org/bugs/show_bug.cgi?id=3D18645 That PR has been languishing a little. I'll see if I can get some attention from the right people upstream. :) > 2. Mesa's configure script is looking for stddef.h here: > /usr/local/llvm34/lib/clang/3.4/include >=20 > LLVM/Clang ports don't install this file. I just added a symlink to > /usr/include/stddef.h and Mesa was happy. I still need to check how > it goes if I remove the check and the symlink. But perhaps Mesa is > right to expect this header (and maybe other) in this directory, I > don't know. Clang provides its own version of a bunch of such headers, such as stddef.h, stdarg.h, and so on, which conflict with our version in base (e.g. /usr/include). Therefore, the base version of clang does not install these, and apparently, neither do the clang ports. On the other hand, I don't really understand why Mesa wants to know *where* a header is exactly located. Normally, in configure scripts or similar, you are only interested in whether the compiler can find it or not. > 3. Our base libc++ has a bug in the header. I posted a PR > on Mesa bug tracker here, before I found out it was a problem with > libc++: > https://bugs.freedesktop.org/show_bug.cgi?id=3D75505 >=20 > Apparently, it's fixed in libc++ upstream, in r199848. I applied that fix to head in r262805, and I will MFC it after 3 days. > 4. At runtime, any OpenCL program segfaults in libc++ (I don't have = the > stack trace at hand and can't remember what it was... Something with > basic_string). >=20 > When using libc++ from ports (devel/libc++, r200683) and the work = around > for problem #1, Clover builds and OpenCL programs run fine. Hm, this is unfortunate. I'm interested in where the difference comes from, and I would ideally like to fix any problem with libc++ in base. Can you point me (privately if you like) to some info on how to build and reproduce? -Dimitry --Apple-Mail=_B8682D86-F6FD-4433-8302-FA7C92A2A179 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMXiOYACgkQsF6jCi4glqPAiACgtOQTLaayj/sMXiJYbBgjQNFN sXsAn2o9CvMULoRDOTEHdARw1V+C/Dfh =fXiD -----END PGP SIGNATURE----- --Apple-Mail=_B8682D86-F6FD-4433-8302-FA7C92A2A179-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 6 13:28:39 2014 Return-Path: Delivered-To: freebsd-toolchain@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 A064E1DD; Thu, 6 Mar 2014 13:28:39 +0000 (UTC) Received: from smtpout3.timeweb.ru (smtpout3.timeweb.ru [92.53.117.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5488D260; Thu, 6 Mar 2014 13:28:38 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WLYLe-0006D2-5A; Thu, 06 Mar 2014 17:28:30 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id A68B2752; Thu, 6 Mar 2014 17:28:29 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 9D7082B876; Thu, 6 Mar 2014 17:28:29 +0400 (MSK) Date: Thu, 6 Mar 2014 17:28:29 +0400 From: Dmitry Marakasov To: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= Subject: Re: Various issues with Clang and libc++ while playing with OpenCL (FYI) Message-ID: <20140306132829.GB92463@hades.panopticon> References: <53170AD1.4090506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53170AD1.4090506@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Content-Transfer-Encoding: quoted-printable Cc: Koop Mast , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:28:39 -0000 * Jean-S=C3=A9bastien P=C3=A9dron (dumbbell@FreeBSD.org) wrote: > 3. Our base libc++ has a bug in the header. I posted a PR > on Mesa bug tracker here, before I found out it was a problem with > libc++: > https://bugs.freedesktop.org/show_bug.cgi?id=3D75505 >=20 > Apparently, it's fixed in libc++ upstream, in r199848. Hm, is this by the chance the same bug as the following? Either way, it would be nice to get it fixed in 10-stable. --- % cat 1.cc=20 #include int main() { std::function f =3D [](){}; return 0; } % clang++ -std=3Dc++11 1.cc=20 % clang++34 -std=3Dc++11 1.cc=20 In file included from 1.cc:1: In file included from /usr/include/c++/v1/functional:465: In file included from /usr/include/c++/v1/memory:603: /usr/include/c++/v1/tuple:320:11: error: rvalue reference to type '' cannot bind to lvalue of type '' : value(__t.get()) ^ ~~~~~~~~~ /usr/include/c++/v1/tuple:444:8: note: in instantiation of member functio= n 'std::__1::__tuple_leaf<0, &&, false>::__tuple_le= af' requested here struct __tuple_impl<__tuple_indices<_Indx...>, _Tp...> ^ /usr/include/c++/v1/functional:1286:26: note: in instantiation of member = function 'std::__1::__function::__func<, std::__1::a= llocator< >, void ()>::__func' requested here ::new (__f_) _FF(_VSTD::move(__f)); ^ 1.cc:3:40: note: in instantiation of function template specialization 'st= d::__1::function::function< >' requested he= re int main() { std::function f =3D [](){}; return 0; } ^ In file included from 1.cc:1: In file included from /usr/include/c++/v1/functional:465: In file included from /usr/include/c++/v1/memory:603: /usr/include/c++/v1/tuple:321:10: error: static_assert failed "Can not co= py a tuple with rvalue reference member" {static_assert(!is_rvalue_reference<_Hp>::value, "Can not copy a = tuple with rvalue reference member");} ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/tuple:320:11: error: rvalue reference to type 'alloca= tor<[...]>' cannot bind to lvalue of type 'allocator<[...]>' : value(__t.get()) ^ ~~~~~~~~~ /usr/include/c++/v1/tuple:444:8: note: in instantiation of member functio= n 'std::__1::__tuple_leaf<0, std::__1::allocator< > = &&, false>::__tuple_leaf' requested here struct __tuple_impl<__tuple_indices<_Indx...>, _Tp...> ^ /usr/include/c++/v1/functional:1294:34: note: in instantiation of member = function 'std::__1::__function::__func<, std::__1::a= llocator< >, void ()>::__func' requested here ::new (__hold.get()) _FF(_VSTD::move(__f), allocator<_Fp>(__a= )); ^ 1.cc:3:40: note: in instantiation of function template specialization 'st= d::__1::function::function< >' requested he= re int main() { std::function f =3D [](){}; return 0; } ^ In file included from 1.cc:1: In file included from /usr/include/c++/v1/functional:465: In file included from /usr/include/c++/v1/memory:603: /usr/include/c++/v1/tuple:321:10: error: static_assert failed "Can not co= py a tuple with rvalue reference member" {static_assert(!is_rvalue_reference<_Hp>::value, "Can not copy a = tuple with rvalue reference member");} ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated. --- --=20 Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 7 16:13:04 2014 Return-Path: Delivered-To: freebsd-toolchain@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 F153EF89; Fri, 7 Mar 2014 16:13:03 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2300A; Fri, 7 Mar 2014 16:13:03 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WLxOO-000Ekq-As; Fri, 07 Mar 2014 17:13:02 +0100 Message-ID: <5319F005.50300@FreeBSD.org> Date: Fri, 07 Mar 2014 17:12:53 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Various issues with Clang and libc++ while playing with OpenCL (FYI) References: <53170AD1.4090506@FreeBSD.org> <08932FE2-8FB5-4EAA-A673-07A3A54721C0@FreeBSD.org> In-Reply-To: <08932FE2-8FB5-4EAA-A673-07A3A54721C0@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucSQ7DbJb3c7EK4PP9jtqmOJuOtxrpwkB" Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:13:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ucSQ7DbJb3c7EK4PP9jtqmOJuOtxrpwkB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2014 21:28, Dimitry Andric wrote: >> 2. Mesa's configure script is looking for stddef.h here: >> /usr/local/llvm34/lib/clang/3.4/include >> >> LLVM/Clang ports don't install this file. I just added a symlink to >> /usr/include/stddef.h and Mesa was happy. I still need to check how >> it goes if I remove the check and the symlink. But perhaps Mesa is >> right to expect this header (and maybe other) in this directory, I >> don't know. >=20 > (...) >=20 > On the other hand, I don't really understand why Mesa wants to know > *where* a header is exactly located. Normally, in configure scripts or= > similar, you are only interested in whether the compiler can find it or= > not. I removed the check for stddef.h and everything build fine. It could be a test tailored for some Linux distributions. >> 3. Our base libc++ has a bug in the header. I posted a PR= >> on Mesa bug tracker here, before I found out it was a problem with >> libc++: >> https://bugs.freedesktop.org/show_bug.cgi?id=3D75505 >=20 > I applied that fix to head in r262805, and I will MFC it after 3 days. I rebuild world and confirm that I don't need to modify anymore. >> 4. At runtime, any OpenCL program segfaults in libc++ (I don't have th= e >> stack trace at hand and can't remember what it was... Something with= >> basic_string). >> >> When using libc++ from ports (devel/libc++, r200683) and the work arou= nd >> for problem #1, Clover builds and OpenCL programs run fine. >=20 > Hm, this is unfortunate. I'm interested in where the difference comes > from, and I would ideally like to fix any problem with libc++ in base. I reproduced the crash but can't restore a working state now. It's on a different computer (newer 11-CURRENT, same libclc/Mesa/OpenCL program) and the crash is a bus error, not a segfault. Here's the backtrace: http://people.freebsd.org/~dumbbell/radeonkms/opencl-crash-1.txt > Can you point me (privately if you like) to some info on how to build > and reproduce? On a computer with WITH_NEW_XORG enabled and a Intel or Radeon GPU (HD 5000+), driven by i915kms/radeonkms (though I didn't try on Intel hardwar= e): 1. You need libdevq: git clone https://github.com/freebsd/libdevq.git It uses autotools: autoreconf -vif ./configure --prefix=3D$PREFIX make make install (I use the same $PREFIX in the following commands) 2. You need libclc: git clone http://llvm.org/git/libclc.git You can configure it like this: python ./configure.py \ --with-llvm-config=3D/usr/local/bin/llvm-config34 \ --prefix=3D$PREFIX gmake gmake install Now is a good time to present you another problem I have with clang 3.4: it eats 100% CPU when building utils/prepare-builtins.cpp and never return. I couldn't reproduce the problem when I wrote my original mail (the only time it worked), that's why I didn't mention it. But now, it's back. Here, I use an older commit and clang 3.3: git checkout c002f62bf03f093521c52e2816e4881afc49ef40 python ./configure.py \ --with-llvm-config=3D/usr/local/bin/llvm-config33 \ --prefix=3D$PREFIX 3. You need Mesa: git clone -b mesa-10.1-rc2-freebsd \ https://github.com/dumbbell/mesa.git To build Mesa, you'll need several ports, some of them comes from the xorg-dev ports tree: svn co https://trillian.chruetertee.ch/svn/ports/trunk Unfortunately, I don't have a ports list at hand... Try to run Mesa's configure script and install ports as required. And install them from xorg-dev first; if the port isn't in xorg-dev, take the one from /usr/ports. Here the configure line I use: (in checkout dir) autoreconf -vif (in checkout dir or separate build dir) /path/to/configure LLVM_CONFIG=3D/usr/local/bin/llvm-config34 \ PKG_CONFIG_PATH=3D$PREFIX/share/pkgconfig:$PREFIX/lib/pkgconfig \ --enable-texture-float --enable-gles2 --enable-osmesa \ --enable-egl --enable-vdpau --enable-shared-glapi \ --enable-glx-tls --enable-gallium-llvm --with-llvm-shared-libs \ --enable-dri --enable-gbm --enable-r600-llvm-compiler \ --with-egl-platforms=3Dx11,drm \ --with-gallium-drivers=3Dradeonsi,swrast,r600,r300,nouveau \ --enable-opencl --prefix=3D$PREFIX CFLAGS=3D"-g -O0" CXXFLAGS=3D"-g= -O0" gmake gmake install 4. And some OpenCL programs: svn co http://opencl-book-samples.googlecode.com/svn/trunk (in a separate build dir) cmake -DOPENCL_LIBRARIES=3D$PREFIX/lib/libOpenCL.so.1 \ -DOPENCL_INCLUDE_DIRS=3D$PREFIX/include -DCMAKE_BUILD_TYPE=3DDebug = \ /path/to/svn-checkout gmake 5. Run an OpenCL program: cd src/Chapter_2/HelloWorld DISPLAY=3D:0 ./HelloWorld An OpenCL requires a running X server, because only the server is allowed to access the CPU (without an X server, the program will fail with Permission denied). I hope I didn't forgot something. I'm available on IRC (as dumbbell or dumbbell-) in any case. My laptop is currently on stable/9; I could setup an account for you once rebooted on -CURRENT, if you don't want to bother with this awful procedure. --=20 Jean-S=E9bastien P=E9dron --ucSQ7DbJb3c7EK4PP9jtqmOJuOtxrpwkB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTGfAMAAoJEDnpl2Gl/ZTMj60QAOWH/xukDMpPgBQirLgoqro+ UvUhfR4NtqRU4Q6JV3EZcThXe1pQL0CJ2VuTLwqB9EzAo0vJF4DeLMQ726tJytJ6 3l4AhS9RDEhKskbDG9FRmifD9S+jCY5BuMCM2TAfGSsWhbldPETm2/NXcspPjPZu WHlUL92y5+Rk/h6MBQ3L7HYAgnWtZFg10Vof2QYMaeRakU5diVL4s7bt9bd5fgSX LlAODIyPI7zF9DZzrCcLRaAEl68D0CQe8mQLsCemiADoP2N6ryKS5eTLd7RTiQ4W pdTjL7HiVVekR1xXzJeEJ0WJWqnY/6VYwUYc6z8k8Lm/SytYe/cU/BLn3NsrT91G jVHJiop3lIOZLj5B2cwJBq3qvFwgNB8XOTwt6BP1C8Snd21ORgeRNzTGQzd6uc9e inyQlu6DHNAVhg7cDEg+xFP1rsnT+ESdVfnGc7wnHKjnjxzfDdJ210kj/uMax+Ml /9HYfPSkHMHlXbWE+H1wewIPyseINLLo+86gSHX1TJWsSUtZ8Aab6iiqsm1Q0ptv NcmwVBf5qvnN+XWVH03530m2xrrIrNq/5jMHRq9JFFZOEJoFKb0bQcpPDiftShm6 nilJcpPlUftyLQh3gK1pjEnLiqoAZXrs3id7WVXuMvfn4FucD4GRiOmKQh/kTQ37 6/prrzuB+/T4ghAJYBez =FPGj -----END PGP SIGNATURE----- --ucSQ7DbJb3c7EK4PP9jtqmOJuOtxrpwkB-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 18 15:38:44 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B262480 for ; Tue, 18 Mar 2014 15:38:44 +0000 (UTC) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id CDCF5221 for ; Tue, 18 Mar 2014 15:38:43 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkIAHFnKFNR8YKK/2dsb2JhbABagwaBBqt0AZdbF3SCZhxfNCqINAGfYrFrjn+EIgSYRYpah1eDLjw Received: from 138.130-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.130.138]) by relay.skynet.be with ESMTP; 18 Mar 2014 16:38:35 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s2IFcYiA032643 for ; Tue, 18 Mar 2014 16:38:35 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Tue, 18 Mar 2014 16:38:34 +0100 From: Tijl Coosemans To: toolchain@FreeBSD.org Subject: clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t Message-ID: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:38:44 -0000 Hi, With -fms-extensions clang 3.4 seems to define a built-in type named __wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h % cat test.c #include % cc -c test.c -fms-extensions In file included from test.c:1: In file included from /usr/include/sys/types.h:44: In file included from /usr/include/machine/endian.h:6: In file included from /usr/include/x86/endian.h:37: In file included from /usr/include/sys/_types.h:33: In file included from /usr/include/machine/_types.h:6: /usr/include/x86/_types.h:145:14: error: cannot combine with previous 'int' declaration specifier typedef int __wchar_t; ^ 1 error generated. What is the best way to resolve this? Maybe rename the FreeBSD __wchar_t to ___wchar_t? From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 18 17:47:37 2014 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 735858D6; Tue, 18 Mar 2014 17:47:37 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BE563D2; Tue, 18 Mar 2014 17:47:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::4de7:6e37:8224:125c] (unknown [IPv6:2001:7b8:3a7:0:4de7:6e37:8224:125c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 55CDC5C45; Tue, 18 Mar 2014 18:47:24 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_FB56A615-682F-4267-8A3D-9424C4122C06"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t From: Dimitry Andric In-Reply-To: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> Date: Tue, 18 Mar 2014 18:47:18 +0100 Message-Id: References: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1874) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:47:37 -0000 --Apple-Mail=_FB56A615-682F-4267-8A3D-9424C4122C06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Mar 2014, at 16:38, Tijl Coosemans wrote: > With -fms-extensions clang 3.4 seems to define a built-in type named > __wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h > > > % cat test.c > #include > % cc -c test.c -fms-extensions > In file included from test.c:1: > In file included from /usr/include/sys/types.h:44: > In file included from /usr/include/machine/endian.h:6: > In file included from /usr/include/x86/endian.h:37: > In file included from /usr/include/sys/_types.h:33: > In file included from /usr/include/machine/_types.h:6: > /usr/include/x86/_types.h:145:14: error: cannot combine with previous 'int' > declaration specifier > typedef int __wchar_t; > ^ > 1 error generated. > > > What is the best way to resolve this? Maybe rename the FreeBSD __wchar_t > to ___wchar_t? Maybe just don't use -fms-extensions, at least not in combination with our system headers? It is not needed for the base system anymore, see r260020, r260102 and r260322. E.g. clang does not need -fms-extensions to stop complaining about anonymous unions, like gcc. Otherwise, the only solution is indeed to rename our __wchar_t. The following type names are reserved in Microsoft mode: __int8 __int16 __int32 __wchar_t -Dimitry --Apple-Mail=_FB56A615-682F-4267-8A3D-9424C4122C06 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMohqkACgkQsF6jCi4glqOPYgCfaFnVqbwl7J15z0smzihI8YZe mMYAoOeecAJLH9XUa3gsDFeel2kP6l3B =dBe4 -----END PGP SIGNATURE----- --Apple-Mail=_FB56A615-682F-4267-8A3D-9424C4122C06-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 19 09:59:15 2014 Return-Path: Delivered-To: freebsd-toolchain@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 B089B736 for ; Wed, 19 Mar 2014 09:59:15 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0A13AE90 for ; Wed, 19 Mar 2014 09:59:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14683 for ; Wed, 19 Mar 2014 11:59:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WQDHA-000F6L-8p for freebsd-toolchain@FreeBSD.org; Wed, 19 Mar 2014 11:59:08 +0200 Message-ID: <53296A34.1060108@FreeBSD.org> Date: Wed, 19 Mar 2014 11:58:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-toolchain@FreeBSD.org Subject: stray warning from gcc's cpp X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 09:59:15 -0000 I observe the following minor annoyance on FreeBSD systems where cpp is GCC's cpp. If a DTrace script has the following shebang line: #!/usr/sbin/dtrace -Cs then the following warning is produced when the script is run: cc1: warning: is shorter than expected Some details. dtrace(1) first forks. Then a child seeks on a file descriptor associated with the script file, so that the shebang line is skipped (because otherwise it would confuse cpp). Then the child makes the file descriptor its standard input and then it execs cpp. cpp performs fstat(2) on its standard input descriptor and determines that it points to a regular file. Then it verifies that a number of bytes it reads from the file is the same as a size of the file. The check makes sense if the file is opened by cpp itself, but it does not always make sense for the stdin as described above. The following patch seems to fix the issue, but perhaps there is a better / smarter alternative. --- a/contrib/gcclibs/libcpp/files.c +++ b/contrib/gcclibs/libcpp/files.c @@ -601,7 +601,8 @@ read_file_guts (cpp_reader *pfile, _cpp_file *file) return false; } - if (regular && total != size && STAT_SIZE_RELIABLE (file->st)) + if (regular && total != size && file->fd != 0 + && STAT_SIZE_RELIABLE (file->st)) cpp_error (pfile, CPP_DL_WARNING, "%s is shorter than expected", file->path); -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 19 10:30:02 2014 Return-Path: Delivered-To: toolchain@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 6E41E9E; Wed, 19 Mar 2014 10:30:02 +0000 (UTC) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id DBC6D1A5; Wed, 19 Mar 2014 10:30:01 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGAFVwKVNR8YKK/2dsb2JhbABagwaBBsJjgRkXdIIlAQEBBCcTHCMQCw4KCSUPKh4GExuHYgHPKheNeWwHhDgBA5hGilqHV4MuPIE1 Received: from 138.130-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.130.138]) by relay.skynet.be with ESMTP; 19 Mar 2014 11:29:52 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s2JATqG8002518; Wed, 19 Mar 2014 11:29:52 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 19 Mar 2014 11:29:52 +0100 From: Tijl Coosemans To: Dimitry Andric Subject: Re: clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t Message-ID: <20140319112952.1384ec64@kalimero.tijl.coosemans.org> In-Reply-To: References: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 10:30:02 -0000 On Tue, 18 Mar 2014 18:47:18 +0100 Dimitry Andric wrote: > On 18 Mar 2014, at 16:38, Tijl Coosemans wrote: >> With -fms-extensions clang 3.4 seems to define a built-in type named >> __wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h >> >> >> % cat test.c >> #include >> % cc -c test.c -fms-extensions >> In file included from test.c:1: >> In file included from /usr/include/sys/types.h:44: >> In file included from /usr/include/machine/endian.h:6: >> In file included from /usr/include/x86/endian.h:37: >> In file included from /usr/include/sys/_types.h:33: >> In file included from /usr/include/machine/_types.h:6: >> /usr/include/x86/_types.h:145:14: error: cannot combine with previous 'int' >> declaration specifier >> typedef int __wchar_t; >> ^ >> 1 error generated. >> >> >> What is the best way to resolve this? Maybe rename the FreeBSD __wchar_t >> to ___wchar_t? > > Maybe just don't use -fms-extensions, at least not in combination with > our system headers? It is not needed for the base system anymore, see > r260020, r260102 and r260322. E.g. clang does not need -fms-extensions > to stop complaining about anonymous unions, like gcc. > > Otherwise, the only solution is indeed to rename our __wchar_t. The > following type names are reserved in Microsoft mode: > > __int8 > __int16 > __int32 > __wchar_t I have a port that uses -fms-extensions for something like this: struct a { int aa; }; struct b { struct a; int bb; }; void test( struct b *arg ) { arg->aa = 1; /* clang errors on this without -fms-extensions */ arg->bb = 2; } Maybe it's a bug (inconsistency) in clang that it accepts the definition of struct b but it doesn't accept accessing the aa field? It cannot be accessed in any other way than in the example above. Anyway, -fms-extensions should work too so I think I'll go ahead and rename __wchar_t. From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 19 20:00:56 2014 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95D5C755; Wed, 19 Mar 2014 20:00:56 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 324C87D9; Wed, 19 Mar 2014 20:00:55 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::a026:571e:e171:37df] (unknown [IPv6:2001:7b8:3a7:0:a026:571e:e171:37df]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 635735C45; Wed, 19 Mar 2014 21:00:47 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_DBB510D3-A524-4324-B39B-5062877AB5BC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: stray warning from gcc's cpp From: Dimitry Andric In-Reply-To: <53296A34.1060108@FreeBSD.org> Date: Wed, 19 Mar 2014 21:00:39 +0100 Message-Id: References: <53296A34.1060108@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 20:00:56 -0000 --Apple-Mail=_DBB510D3-A524-4324-B39B-5062877AB5BC Content-Type: multipart/mixed; boundary="Apple-Mail=_F8E5405F-2B48-46A8-8271-D8CEABB85882" --Apple-Mail=_F8E5405F-2B48-46A8-8271-D8CEABB85882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2014, at 10:58, Andriy Gapon wrote: >=20 > I observe the following minor annoyance on FreeBSD systems where cpp = is GCC's > cpp. If a DTrace script has the following shebang line: > #!/usr/sbin/dtrace -Cs > then the following warning is produced when the script is run: > cc1: warning: is shorter than expected >=20 > Some details. dtrace(1) first forks. Then a child seeks on a file = descriptor > associated with the script file, so that the shebang line is skipped = (because > otherwise it would confuse cpp). Then the child makes the file = descriptor its > standard input and then it execs cpp. cpp performs fstat(2) on its = standard > input descriptor and determines that it points to a regular file. = Then it > verifies that a number of bytes it reads from the file is the same as = a size of > the file. The check makes sense if the file is opened by cpp itself, = but it > does not always make sense for the stdin as described above. >=20 > The following patch seems to fix the issue, but perhaps there is a = better / > smarter alternative. >=20 > --- a/contrib/gcclibs/libcpp/files.c > +++ b/contrib/gcclibs/libcpp/files.c > @@ -601,7 +601,8 @@ read_file_guts (cpp_reader *pfile, _cpp_file = *file) > return false; > } >=20 > - if (regular && total !=3D size && STAT_SIZE_RELIABLE (file->st)) > + if (regular && total !=3D size && file->fd !=3D 0 > + && STAT_SIZE_RELIABLE (file->st)) > cpp_error (pfile, CPP_DL_WARNING, > "%s is shorter than expected", file->path); Something like the attached diff, perhaps? This just gets the current file pointer offset, and adds it to the total number of bytes read. The sum must still match the fstat'd size, of course. For files opened by cpp itself there is no functional change, but it does seem to fix the problem case you have described. -Dimitry --Apple-Mail=_F8E5405F-2B48-46A8-8271-D8CEABB85882 Content-Disposition: attachment; filename=fix-dtrace-gnu-cpp-1.diff Content-Type: application/octet-stream; name="fix-dtrace-gnu-cpp-1.diff" Content-Transfer-Encoding: 7bit Index: contrib/gcclibs/libcpp/files.c =================================================================== --- contrib/gcclibs/libcpp/files.c (revision 263376) +++ contrib/gcclibs/libcpp/files.c (working copy) @@ -545,7 +545,7 @@ static bool read_file_guts (cpp_reader *pfile, _cpp_file *file) { - ssize_t size, total, count; + ssize_t size, offset, total, count; uchar *buf; bool regular; @@ -573,12 +573,21 @@ } size = file->st.st_size; + + if ((offset = (ssize_t)lseek(file->fd, (off_t)0, SEEK_CUR)) < 0) + { + cpp_error (pfile, CPP_DL_ERROR, "%s has no current position", file->path); + return false; + } } else - /* 8 kilobytes is a sensible starting size. It ought to be bigger - than the kernel pipe buffer, and it's definitely bigger than - the majority of C source files. */ - size = 8 * 1024; + { + /* 8 kilobytes is a sensible starting size. It ought to be bigger + than the kernel pipe buffer, and it's definitely bigger than + the majority of C source files. */ + size = 8 * 1024; + offset = 0; + } buf = XNEWVEC (uchar, size + 1); total = 0; @@ -586,7 +595,7 @@ { total += count; - if (total == size) + if (offset + total == size) { if (regular) break; @@ -601,7 +610,7 @@ return false; } - if (regular && total != size && STAT_SIZE_RELIABLE (file->st)) + if (regular && offset + total != size && STAT_SIZE_RELIABLE (file->st)) cpp_error (pfile, CPP_DL_WARNING, "%s is shorter than expected", file->path); --Apple-Mail=_F8E5405F-2B48-46A8-8271-D8CEABB85882 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F8E5405F-2B48-46A8-8271-D8CEABB85882-- --Apple-Mail=_DBB510D3-A524-4324-B39B-5062877AB5BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMp920ACgkQsF6jCi4glqMFvQCg7A8l2mUOm78CZY9iwq5NHaAJ 3H0Anj9TL90PJZ1szhny+OiuoGOZYcQk =ztpM -----END PGP SIGNATURE----- --Apple-Mail=_DBB510D3-A524-4324-B39B-5062877AB5BC-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 23 16:59:36 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12C9026A for ; Sun, 23 Mar 2014 16:59:36 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2D27D34 for ; Sun, 23 Mar 2014 16:59:35 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so4497007iec.1 for ; Sun, 23 Mar 2014 09:59:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version; bh=KLeJPjEeDtNubDReN1o+wAC/TIQHQdjPE3EX47q86AA=; b=VLVKIs6Mp83V6IbekZkroIXjNdFMC4hAx0exU4Kch3S6axixFWicR8K0qg9+USQAzC Hprg+Xhfv4OFXdIaQjIYUpSA+y8M53zw8tQO+xfl2SiTLCXuc/e8pyQ1eUkz0HCNmy/Q AL+2YL2eFLHTWaNns7pXEU88tlWhwqXjRhiDN3KJDCb/1GLbSMCO049SWMXSjX6/m1Fb a1fDG+h3LPrg899j9SnyLRGTkIVTlaaxmXqr2bjumDQcqxmluxikQCEa6Z4Ph7wmC22v X7ykueNVOoJIIPMd0n49HM8F413GJi2UIxwVSYqTLEqBlnxziKnYGEj1muaVI2Tf/6Ly QTYQ== X-Gm-Message-State: ALoCoQnlwIrHbxuMTHwDdXXNj9JbuLDDZmjrlXDoJJzm+8lIasZlLeovq113y7vd0LVfPi+RANRO X-Received: by 10.50.56.109 with SMTP id z13mr7416175igp.6.1395593974663; Sun, 23 Mar 2014 09:59:34 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm17869855igc.8.2014.03.23.09.59.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Mar 2014 09:59:33 -0700 (PDT) Sender: Warner Losh From: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Fwd: [releng_10 tinderbox] failure on arm/arm Date: Sun, 23 Mar 2014 10:59:32 -0600 References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> To: freebsd-arm , toolchain@freebsd.org Message-Id: <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:59:36 -0000 About the time clang was MFC=92d, this started appearing. It has been = several days now. Did the clang MFC botch something? Was the timing just a coincidence? Warner Begin forwarded message: > From: FreeBSD Tinderbox > Subject: [releng_10 tinderbox] failure on arm/arm > Date: March 23, 2014 at 9:22:05 AM MDT > To: FreeBSD Tinderbox , , = >=20 > TB --- 2014-03-23 12:30:45 - tinderbox 2.20 running on = worker01.tb.des.no > TB --- 2014-03-23 12:30:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 = FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2014-03-23 12:30:45 - starting RELENG_10 tinderbox run for = arm/arm > TB --- 2014-03-23 12:30:45 - cleaning the object tree > TB --- 2014-03-23 12:31:16 - /usr/local/bin/svn stat --no-ignore /src > TB --- 2014-03-23 12:32:03 - At svn revision 263659 > TB --- 2014-03-23 12:32:04 - building world > TB --- 2014-03-23 12:32:04 - CROSS_BUILD_TESTING=3DYES > TB --- 2014-03-23 12:32:04 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2014-03-23 12:32:04 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-03-23 12:32:04 - SRCCONF=3D/dev/null > TB --- 2014-03-23 12:32:04 - TARGET=3Darm > TB --- 2014-03-23 12:32:04 - TARGET_ARCH=3Darm > TB --- 2014-03-23 12:32:04 - TZ=3DUTC > TB --- 2014-03-23 12:32:04 - __MAKE_CONF=3D/dev/null > TB --- 2014-03-23 12:32:04 - cd /src > TB --- 2014-03-23 12:32:04 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Sun Mar 23 12:32:13 UTC 2014 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies > [...] > /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: = ARM_NARCH is 0 > #error ARM_NARCH is 0 > ^ > /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: = ARM_NMMUS is 0 > #error ARM_NMMUS is 0 > ^ > 2 errors generated. > mkdep: compile failed > *** Error code 1 >=20 > Stop. > bmake[3]: stopped in /src/usr.sbin/route6d > *** Error code 1 >=20 > Stop. > bmake[2]: stopped in /src/usr.sbin > *** Error code 1 >=20 > Stop. > bmake[1]: stopped in /src > *** Error code 1 >=20 > Stop. > bmake: stopped in /src > *** [buildworld] Error code 1 >=20 > Stop in /src. > TB --- 2014-03-23 15:22:05 - WARNING: /usr/bin/make returned exit code = 1=20 > TB --- 2014-03-23 15:22:05 - ERROR: failed to build world > TB --- 2014-03-23 15:22:05 - 8213.05 user 2072.59 system 10279.23 real >=20 >=20 > = http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 23 21:32:15 2014 Return-Path: Delivered-To: toolchain@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 ADDF577E; Sun, 23 Mar 2014 21:32:15 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A7BA92B; Sun, 23 Mar 2014 21:32:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b9f0:3633:d663:add7] (unknown [IPv6:2001:7b8:3a7:0:b9f0:3633:d663:add7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4694F5C43; Sun, 23 Mar 2014 22:32:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Dimitry Andric In-Reply-To: <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Date: Sun, 23 Mar 2014 22:31:58 +0100 Message-Id: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: toolchain@freebsd.org, freebsd-arm X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 21:32:15 -0000 --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 23 Mar 2014, at 17:59, Warner Losh wrote: > About the time clang was MFC=92d, this started appearing. It has been = several days now. >=20 > Did the clang MFC botch something? Was the timing just a coincidence? I hope the latter, but I didn't investigate yet. I do know that I ran a make universe before the clang 3.4 merge, and that worked just fine. That said, at first glance this looks like some sort of scripting problem? Does anybody know off the top of their heads where ARM_NARCH and ARM_NMMUS are coming from? -Dimitry --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMvUtEACgkQsF6jCi4glqNwdQCgx3joabmx/I3AvpyTnLen9RWg 3r8AnRfhvmBqK+RvihvHs2kq7CN4CoOj =KQec -----END PGP SIGNATURE----- --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 23 21:57:40 2014 Return-Path: Delivered-To: toolchain@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 DB02FB40; Sun, 23 Mar 2014 21:57:40 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AAFEDAB0; Sun, 23 Mar 2014 21:57:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WRqOh-0000mw-DB; Sun, 23 Mar 2014 21:57:39 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2NLvapd074529; Sun, 23 Mar 2014 15:57:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+F5KMVbD0rRY4G9sMml+3P Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Ian Lepore To: Dimitry Andric In-Reply-To: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sun, 23 Mar 2014 15:57:36 -0600 Message-ID: <1395611856.81853.54.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s2NLvapd074529 Cc: toolchain@FreeBSD.org, freebsd-arm X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 21:57:40 -0000 On Sun, 2014-03-23 at 22:31 +0100, Dimitry Andric wrote: > On 23 Mar 2014, at 17:59, Warner Losh wrote: > > About the time clang was MFC=A2d, this started appearing. It has been= several days now. > >=20 > > Did the clang MFC botch something? Was the timing just a coincidence? >=20 > I hope the latter, but I didn't investigate yet. I do know that I ran = a > make universe before the clang 3.4 merge, and that worked just fine. >=20 > That said, at first glance this looks like some sort of scripting > problem? Does anybody know off the top of their heads where ARM_NARCH > and ARM_NMMUS are coming from? >=20 > -Dimitry >=20 from sys/arm/include/cpuconf.h. iirc, they use some compiler predefined macros. -- Ian From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 23 22:51:15 2014 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5A3BA6C; Sun, 23 Mar 2014 22:51:15 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B949F4B; Sun, 23 Mar 2014 22:51:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b9f0:3633:d663:add7] (unknown [IPv6:2001:7b8:3a7:0:b9f0:3633:d663:add7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 71A475C43; Sun, 23 Mar 2014 23:51:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Dimitry Andric In-Reply-To: <1395611856.81853.54.camel@revolution.hippie.lan> Date: Sun, 23 Mar 2014 23:50:51 +0100 Message-Id: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> <1395611856.81853.54.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: toolchain@FreeBSD.org, freebsd-arm , Gleb Smirnoff X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 22:51:16 -0000 --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On 23 Mar 2014, at 22:57, Ian Lepore wrote: > On Sun, 2014-03-23 at 22:31 +0100, Dimitry Andric wrote: >> On 23 Mar 2014, at 17:59, Warner Losh wrote: >>> About the time clang was MFC=A2d, this started appearing. It has = been several days now. >>>=20 >>> Did the clang MFC botch something? Was the timing just a = coincidence? >>=20 >> I hope the latter, but I didn't investigate yet. I do know that I = ran a >> make universe before the clang 3.4 merge, and that worked just fine. >>=20 >> That said, at first glance this looks like some sort of scripting >> problem? Does anybody know off the top of their heads where = ARM_NARCH >> and ARM_NMMUS are coming from? >>=20 >> -Dimitry >>=20 >=20 > from sys/arm/include/cpuconf.h. iirc, they use some compiler = predefined > macros. I just had a look at the full build log, and it died here: =3D=3D=3D> usr.sbin/route6d (depend) rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DHAVE_POLL_H -std=3Dgnu99 = /src/usr.sbin/route6d/route6d.c In file included from /src/usr.sbin/route6d/route6d.c:68: In file included from /obj/arm.arm/src/tmp/usr/include/net/route.h:36: In file included from /obj/arm.arm/src/tmp/usr/include/sys/counter.h:35: In file included from = /obj/arm.arm/src/tmp/usr/include/machine/counter.h:32: In file included from /obj/arm.arm/src/tmp/usr/include/sys/pcpu.h:48: In file included from = /obj/arm.arm/src/tmp/usr/include/machine/pcpu.h:35: /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: = ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: = ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. The parts in cpuconf.h that produce this error are: #if ARM_NARCH =3D=3D 0 && !defined(KLD_MODULE) && defined(_KERNEL) #error ARM_NARCH is 0 #endif [...] #if ARM_NMMUS =3D=3D 0 && !defined(KLD_MODULE) && defined(_KERNEL) #error ARM_NMMUS is 0 #endif so this error was most likely caused by route6d.c defining _KERNEL to 1 before including . I expect that Gleb Smirnoff's r263668 (which removes the _KERNEL define again) will fix it. -Dimitry --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMvZVcACgkQsF6jCi4glqN3FwCdHaaxoSY1cqhsMYuVwK5Qq90C A4EAoOH3+7Pjhfh+ezYH04vntav4N8ii =3w3y -----END PGP SIGNATURE----- --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 26 00:22:17 2014 Return-Path: Delivered-To: freebsd-toolchain@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 136BBFEE; Wed, 26 Mar 2014 00:22:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD7F3998; Wed, 26 Mar 2014 00:22:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s2Q0M5jP010046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Mar 2014 17:22:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s2Q0M5j5010045; Tue, 25 Mar 2014 17:22:05 -0700 (PDT) (envelope-from sgk) Date: Tue, 25 Mar 2014 17:22:05 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org, freebsd-toolchain@freebsd.org Subject: clang is almost useless for complex arithmetic Message-ID: <20140326002205.GA9940@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 00:22:17 -0000 It appears that clang developers have chosen the naive complex division algorithm, and it does not matter whether one turns CX_LIMITED_RANGE on or off. This means that if one uses clang with complex types, one must be careful with the range of values allowed in complex division. In other words, implementation of complex libm routines cannot use complex data types and must fallback to a decomposition into real and imaginary components. For the record, I am using % cc --version FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 Target: x86_64-unknown-freebsd11.0 With the program that follows my sig, if I do % cc -o z -O -DOFF cmplx.c -lm && ./z > pragma_off % cc -o z -O cmplx.c -lm && ./z > pragma_on % diff -u pragma_off pragma_on | wc -l 0 % cat pragma_on Expected: 0x1p-1023 -0x1p-1023 Compiler: 0x0p+0 -0x0p+0 Improved: 0x1p-1023 -0x1p-1023 Expected: 0x1p+1023 0x0p+0 Compiler: inf nan Improved: 0x1p+1023 0x0p+0 Expected: 0x1p+346 -0x1p-1008 Compiler: nan -0x0p+0 Improved: 0x1p+346 -0x1p-1008 Expected: 0x1p+1023 0x0p+0 Compiler: inf 0x0p+0 Improved: 0x1p+1023 0x0p+0 Expected: 0x1p+364 -0x1p-1072 Compiler: nan -0x0p+0 Improved: 0x1p+364 -0x1p-1072 Expected: 0x1p-1072 0x1p+20 Compiler: 0x0p+0 nan Improved: 0x1p-1072 0x1p+20 Expected: 0x1.ffffffffff8p+961 0x1.ffffffffff8p+982 Compiler: nan nan Improved: 0x1.ffffffffff8p+961 0x1.ffffffffff8p+982 Expected: 0x1.3333333333333p-1 0x1.999999999999ap-3 Compiler: nan nan Improved: 0x1.3333333333333p-1 0x1.999999999999ap-3 Expected: 0x1p-9 -0x1p-9 Compiler: nan nan Improved: 0x1p-9 -0x1p-9 Expected: 0x1p-279 0x1.f8p-729 Compiler: 0x1p-279 0x0p+0 Improved: 0x1p-279 0x1.f8p-729 Here, "Expected" is the expected result. "Compiler" is what clang produces. "Improved" implements the algorithm suggested in Michael Baudin, Robert L. Smith, "A Robust Complex Division in Scilab," http://arxiv.org/abs/1210.4539 -- Steve #include #include #include #include #include #ifdef OFF #pragma CX_LIMITED_RANGE off #else #pragma CX_LIMITED_RANGE on #endif typedef union { double complex f; double a[2]; } double_complex; #define REALPART(z) ((z).a[0]) #define IMAGPART(z) ((z).a[1]) static __inline double complex cpack(double x, double y) { double_complex z; REALPART(z) = x; IMAGPART(z) = y; return (z.f); } /* * For details of internal() and divi() see: * Michael Baudin, Robert L. Smith, "A Robust Complex Division in Scilab," * http://arxiv.org/abs/1210.4539 */ double complex internal(double a, double b, double c, double d, int l) { static const double ti = 0x1.p-1022, rti = 0x1.p1022, hu = 0x1.p1023, rhu = 0x1.p-1023; double e, f, r, t, ma, mi; r = d / c; if (r != 0) { if (fabs(c) < rhu) { t = c * hu + d * hu * r; e = (a * hu + b * hu * r) / t; f = (b * hu - a * hu * r) / t; } else if (fabs(c) > rti) { t = 1 / (c * ti + d * ti * r); e = (a * ti + b * ti * r) * t; f = (b * ti - a * ti * r) * t; } else { t = 1 / (c + d * r); ma = fmax(fabs(a), fabs(b)); mi = fmin(fabs(a), fabs(b)); if (ma < rti && mi * r > rhu) { e = (a + b * r) * t; f = (b - a * r) * t; } else { r = r * t; e = a * t + b * r; f = b * t - a * r; } } } else { t = 1 / c; e = (a + d * (b / c)) * t; f = (b - d * (a / c)) * t; } if (l == 1) f = -f; return (cpack(e, f)); } double complex divi(double complex z1, double complex z2) { double complex r; double a, b, c, d; a = creal(z1); b = cimag(z1); c = creal(z2); d = cimag(z2); if (fabs(d) <= fabs(c)) r = internal(a, b, c, d, 0); else r = internal(b, a, d, c, 1); return (r); } int main(void) { /* Numerators. */ double complex x[10] = { cpack(1, 1), cpack(1, 1), cpack(0x1.p1023, 0x1.p-1023), cpack(0x1.p1023, 0x1.p1023), cpack(0x1.p1020, 0x1.p-844), cpack(0x1.p-71, 0x1.p1021), cpack(0x1.p-347, 0x1.p-54), cpack(0x1.p-1074, 0x1.p-1074), cpack(0x1.p1015, 0x1.p-989), cpack(0x1.p-622, 0x1.p-1071) }; /* Denominators. */ double complex y[10] = { cpack(1, 0x1.p1023), cpack(0x1.p-1023, 0x1.p-1023), cpack(0x1.p677, 0x1.p-677), cpack(1, 1), cpack(0x1.p656, 0x1.p-780), cpack(0x1.p1001, 0x1.p-323), cpack(0x1.p-1037, 0x1.p-1058), cpack(0x1.p-1073, 0x1.p-1074), cpack(0x1.p1023, 0x1.p1023), cpack(0x1.p-343, 0x1.p-798) }; double complex r[10] = { cpack(0x1.p-1023, -0x1.p-1023), cpack(0x1.p1023, 0), cpack(0x1.p346, -0x1.p-1008), cpack(0x1.p1023, 0), cpack(0x1.p364, -0x1.p-1072), cpack(0x1.p-1072, 0x1.p20), cpack(3.898125604559113300E289, 8.174961907852353577E295), cpack(0.6, 0.2), cpack(0.001953125, -0.001953125), cpack(1.02951151789360578E-84, 6.97145987515076231E-220) }; double complex a, z[10]; int j; for (j = 0; j < 10; j++) { z[j] = x[j] / y[j]; a = divi(x[j], y[j]); printf("Expected: %la %la\n", creal(r[j]), cimag(r[j])); printf("Compiler: %la %la\n", creal(z[j]), cimag(z[j])); printf("Improved: %la %la\n", creal(a), cimag(a)); printf("\n"); } return 0; } From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 26 20:00:14 2014 Return-Path: Delivered-To: freebsd-toolchain@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 501C1610; Wed, 26 Mar 2014 20:00:14 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BAEB366; Wed, 26 Mar 2014 20:00:13 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::5cdf:5701:2dff:9241] (unknown [IPv6:2001:7b8:3a7:0:5cdf:5701:2dff:9241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 39CCB5C43; Wed, 26 Mar 2014 21:00:05 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_4D60DC5B-59BF-4A7A-9400-B8EC0CCD811E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: stray warning from gcc's cpp From: Dimitry Andric In-Reply-To: Date: Wed, 26 Mar 2014 20:59:55 +0100 Message-Id: <43ADA601-3DE6-47AB-86F1-CDAB15BB0C50@FreeBSD.org> References: <53296A34.1060108@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 20:00:14 -0000 --Apple-Mail=_4D60DC5B-59BF-4A7A-9400-B8EC0CCD811E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2014, at 21:00, Dimitry Andric wrote: > On 19 Mar 2014, at 10:58, Andriy Gapon wrote: >>=20 >> I observe the following minor annoyance on FreeBSD systems where cpp = is GCC's >> cpp. If a DTrace script has the following shebang line: >> #!/usr/sbin/dtrace -Cs >> then the following warning is produced when the script is run: >> cc1: warning: is shorter than expected >>=20 >> Some details. dtrace(1) first forks. Then a child seeks on a file = descriptor >> associated with the script file, so that the shebang line is skipped = (because >> otherwise it would confuse cpp). Then the child makes the file = descriptor its >> standard input and then it execs cpp. cpp performs fstat(2) on its = standard >> input descriptor and determines that it points to a regular file. = Then it >> verifies that a number of bytes it reads from the file is the same as = a size of >> the file. The check makes sense if the file is opened by cpp itself, = but it >> does not always make sense for the stdin as described above. ... I committed an updated fix in r263775. -Dimitry --Apple-Mail=_4D60DC5B-59BF-4A7A-9400-B8EC0CCD811E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMzMcAACgkQsF6jCi4glqMaIgCgyifXLZ1jBoCAhBeLBd7mZfww AmsAoI5Axjdomr9raYQx2XzGPG783tCA =vHx7 -----END PGP SIGNATURE----- --Apple-Mail=_4D60DC5B-59BF-4A7A-9400-B8EC0CCD811E-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Apr 9 13:19:33 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E7D9505 for ; Wed, 9 Apr 2014 13:19:33 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1CCD1697 for ; Wed, 9 Apr 2014 13:19:32 +0000 (UTC) Received: from mail-wg0-f51.google.com ([74.125.82.51]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKU0VIyGAo7aCHIu+AChqtYesiScZhmuhi@postini.com; Wed, 09 Apr 2014 13:19:33 UTC Received: by mail-wg0-f51.google.com with SMTP id k14so2478702wgh.22 for ; Wed, 09 Apr 2014 06:19:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=0Pe//dlwm8Q4/F3YVjliLDEKMox3TYOut0VQeNGj7f4=; b=aXRuqEr8oloUt0AuNiD+9sB2LQfFpoy9rSh2KlnGaIJUd4mUhqdI2bDic3Qp8qkDAx fvrPVb1OnGswFU9q8Fw4S70m6YcmEyp62oaP/B8J5rF36JXVwzywOc0nf7CAfjbgya+4 x/RGPBj3rT9Rm5NI6eszl922FDH3fHRa7aK5VEFsSH1hFhOw1C5Ou3l9+tboUsyJOXBo E75W8hVEWZ7z7XmTxxnq/vXwVAiTSrX6dC5CTbseRz7YQ0iwUPN0TASB3JyZbR0oOyJC bl2mzlASGwT4mdejNPmqSeelGBHPHJtV7nCtVTaLQ/XcmQ2CKsd8Xh/HrsvmYbzM8Etw wyoA== X-Gm-Message-State: ALoCoQnT2W5TlkqgmESaUtkqXWxD5MGRtX+2V8tDld9THo8c4LBvIdzP0EnMHT1CQIZTzuCO0y6mXJ+qAaW5ZAtz+N5YMqc9mIGsAgRX/bVcIHjUL+6ek71Ov93VsxSgZLvp2nYbcYjw X-Received: by 10.194.7.196 with SMTP id l4mr79939wja.92.1397049544408; Wed, 09 Apr 2014 06:19:04 -0700 (PDT) X-Received: by 10.194.7.196 with SMTP id l4mr79922wja.92.1397049544239; Wed, 09 Apr 2014 06:19:04 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id f1sm10057989wic.19.2014.04.09.06.19.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Apr 2014 06:19:03 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6) with ESMTP id s39DJ2Ik028756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Apr 2014 14:19:02 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6/Submit) id s39DJ2To028755 for toolchain@freebsd.org; Wed, 9 Apr 2014 14:19:02 +0100 (BST) (envelope-from mexas) Date: Wed, 9 Apr 2014 14:19:02 +0100 (BST) From: Anton Shterenlikht Message-Id: <201404091319.s39DJ2To028755@mech-cluster241.men.bris.ac.uk> To: toolchain@freebsd.org Subject: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:19:33 -0000 I haven't tried gfortran on amd64 for a long time, so I'm probably doing something wrong: On ia64 11-current: $ cat z.f90 end $ gfortran47 z.f90 $ ./a.out $ On amd64 11-current: $ cat z.f90 end $ gfortran47 z.f90 $ ./a.out /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found $ $ gfortran48 z.f90 $ ./a.out /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found $ gfortran49 z.f90 $ ./a.out /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found $ On both systems gcc ports are installed via pkg - the official packages on amd64, and my own packages on ia64. Am I missing on some compiler/linker options? Or did gcc packages did not istall correctly on amd64? Thanks Anton From owner-freebsd-toolchain@FreeBSD.ORG Tue Apr 15 05:32:56 2014 Return-Path: Delivered-To: toolchain@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 0E7CC1B2 for ; Tue, 15 Apr 2014 05:32:56 +0000 (UTC) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id DEE4F1B3A for ; Tue, 15 Apr 2014 05:32:55 +0000 (UTC) Received: from [10.10.34.27] (unknown [108.60.106.91]) by ainaz.pair.com (Postfix) with ESMTPSA id 6E5323F40F; Tue, 15 Apr 2014 01:32:44 -0400 (EDT) Date: Tue, 15 Apr 2014 00:32:41 -0700 (PDT) From: Gerald Pfeifer To: Anton Shterenlikht Subject: Re: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found In-Reply-To: <201404091319.s39DJ2To028755@mech-cluster241.men.bris.ac.uk> Message-ID: References: <201404091319.s39DJ2To028755@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:32:56 -0000 On Wed, 9 Apr 2014, Anton Shterenlikht wrote: > I haven't tried gfortran on amd64 for a long time, > so I'm probably doing something wrong: > > On ia64 11-current: > > $ cat z.f90 > end > $ gfortran47 z.f90 > $ ./a.out > $ > > On amd64 11-current: > > $ cat z.f90 > end > $ gfortran47 z.f90 > $ ./a.out > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found > $ > $ gfortran48 z.f90 > $ ./a.out > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found > $ gfortran49 z.f90 > $ ./a.out > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found > $ > > On both systems gcc ports are installed > via pkg - the official packages on amd64, > and my own packages on ia64. Can you please check out the new pkg-message I added for lang/gcc49 and lang/gcc48 a couple of days ago? > Am I missing on some compiler/linker options? Yes. Setting LD_LIBRARY_PATH or using -Wl,rpath=/usr/local/lib/gcc47/ should fix this for you. Gerald From owner-freebsd-toolchain@FreeBSD.ORG Wed Apr 16 15:40:04 2014 Return-Path: Delivered-To: toolchain@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 B7769DC8 for ; Wed, 16 Apr 2014 15:40:04 +0000 (UTC) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 148651C6F for ; Wed, 16 Apr 2014 15:40:03 +0000 (UTC) Received: from mail-wg0-f44.google.com ([74.125.82.44]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKU06kOCJrgBkHmflrK7GGrNamzRpM6M0U@postini.com; Wed, 16 Apr 2014 15:40:04 UTC Received: by mail-wg0-f44.google.com with SMTP id m15so10980286wgh.3 for ; Wed, 16 Apr 2014 08:39:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=b9ZF1PCRUIB2kcIshM8e2a8F5HNc5XlTFJJPPjKfVY8=; b=IsijJO8ITrixYlnZL6OomL/n1cYP33vFBvsm7N0r7QaQLylmyL6riiwKLAB3KM8cP/ 6scHDqGLoO7SYr8Et0XV56lgZ0DVDaqWvszy70NFsuJrFjZqamNPhjp4oBgkEUjTMpk2 z2rIo8hYXLU4BoS5aHMQme3apUeIuGxqccVe2si+QakfuXwueI3BVxbVWDtFwb7ORSQk UGQKjAk0r9nQ5FyZgZqURHRBXc0g6rXixWgoBP9KJUR0zZ/c8ztezGLY8CrVeq1btiiF SdLGM7rdDuWJEUJZu1OGhcx533yMjRD/0XGl6TJBeu+qnbaHP2pGS4feg+ihglgrtb7G 16Bg== X-Gm-Message-State: ALoCoQneCDvITmid2nDefJvYh+BC8gsQH7CX6AJ+ll7/ntTeb2QwLj1KGRm/AsmB6kVeCO5K/c2DzbGcZnKMCuF7iVIX92EUEp4twq9i2z3CIZCqQpbYMEAnpP+hiZ21BnEKRbX9O3/X X-Received: by 10.180.160.205 with SMTP id xm13mr529956wib.22.1397662776444; Wed, 16 Apr 2014 08:39:36 -0700 (PDT) X-Received: by 10.180.160.205 with SMTP id xm13mr529937wib.22.1397662776297; Wed, 16 Apr 2014 08:39:36 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id bq12sm15470314wib.0.2014.04.16.08.39.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Apr 2014 08:39:35 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s3GFdY6T020766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Apr 2014 16:39:34 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s3GFdXto020765; Wed, 16 Apr 2014 16:39:33 +0100 (BST) (envelope-from mexas) Date: Wed, 16 Apr 2014 16:39:33 +0100 (BST) From: Anton Shterenlikht Message-Id: <201404161539.s3GFdXto020765@mech-cluster241.men.bris.ac.uk> To: gerald@pfeifer.com, mexas@bris.ac.uk Subject: Re: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found In-Reply-To: Cc: toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:40:04 -0000 >From gerald@pfeifer.com Tue Apr 15 07:27:28 2014 > >On Wed, 9 Apr 2014, Anton Shterenlikht wrote: >> I haven't tried gfortran on amd64 for a long time, >> so I'm probably doing something wrong: >> >> On ia64 11-current: >> >> $ cat z.f90 >> end >> $ gfortran47 z.f90 >> $ ./a.out >> $ >> >> On amd64 11-current: >> >> $ cat z.f90 >> end >> $ gfortran47 z.f90 >> $ ./a.out >> /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found >> $ >> $ gfortran48 z.f90 >> $ ./a.out >> /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found >> $ gfortran49 z.f90 >> $ ./a.out >> /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found >> $ >> >> On both systems gcc ports are installed >> via pkg - the official packages on amd64, >> and my own packages on ia64. > >Can you please check out the new pkg-message I added for lang/gcc49 >and lang/gcc48 a couple of days ago? Sorry, not sure what you mean here. I've checked "pkg info -xf gcc". Do you mean that bootstrap is now ON by default in 48 and 49? > >> Am I missing on some compiler/linker options? > >Yes. Setting LD_LIBRARY_PATH or using -Wl,rpath=/usr/local/lib/gcc47/ >should fix this for you. ok, this works. Just need to add a dash in front of rpath. Thanks Anton From owner-freebsd-toolchain@FreeBSD.ORG Thu May 1 01:01:14 2014 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C06EE4A5; Thu, 1 May 2014 01:01:14 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (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 2371E1BEA; Thu, 1 May 2014 01:01:11 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id ib6so3206964vcb.5 for ; Wed, 30 Apr 2014 18:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=sfJYsbTjnCaxJUuXgQX+TZS/DDjcE9XN8NrLnnQ08hs=; b=bgYuoTbE0X/RpBSpjEL8Y2UchLAdVZ8OssjwdIEMn5JAT37PwLPYhIrDW7iFkubTDf gtyvwIALrSw21ynRib8KVTf3qW0ScuLklrUZNcNE/VUJu1tLmJ8gkDUp97N6P/NgyQaB CfubmaMTN3kK8ZqL+cgtAX1ANXNulHePV/T6h/nGPwYQuupmaLRCiOvU/lJHma5HTaIn eYu36YC4a8p/0GEDBgpTg/ve6RExSKA5b5rAVaA1s40tMhAuQm87Tj5rQNKSDb1Z67/q AWIrbvxKIXuvd5pS5FusXXNnS5heQnGxFBjcW+lX9a5Ocy+53E7akKVRSFDFg1BfGw0+ d8zQ== MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr6037122vcx.1.1398906070267; Wed, 30 Apr 2014 18:01:10 -0700 (PDT) Received: by 10.221.67.136 with HTTP; Wed, 30 Apr 2014 18:01:10 -0700 (PDT) Date: Wed, 30 Apr 2014 18:01:10 -0700 Message-ID: Subject: Help with review/commit of conf/189156? From: Garrett Cooper To: dfr@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Cc: sunpoet@FreeBSD.org, freebsd-current@freebsd.org, freebsd-ports@FreeBSD.org, freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:01:14 -0000 Hello all, I was wondering if someone could please look at committing this enhancement for src. It would fix compiling ftp/curl (which gets pulled in via devel/git and a number of other tools) when ${MK_GSSAPI} => no. As it stands, the headers always get installed regardless of whether or not the libraries get installed in the base system, and the knob in ports looks for /usr/include/gssapi* for keying whether or not to automatically enable gssapi/kerberos support. Thank you!!! -Garrett ---------- Forwarded message ---------- From: Date: Wed, Apr 30, 2014 at 5:00 PM Subject: Re: conf/189156: include/Makefile does not honor MK_GSSAPI == no To: Garrett Cooper Thank you very much for your problem report. It has the internal identification `conf/189156'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=189156 >Category: conf >Responsible: freebsd-bugs >Synopsis: include/Makefile does not honor MK_GSSAPI == no >Arrival-Date: Thu May 01 00:00:00 UTC 2014 From owner-freebsd-toolchain@FreeBSD.ORG Tue Jun 10 01:48:09 2014 Return-Path: Delivered-To: freebsd-toolchain@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 7AC5C7C7 for ; Tue, 10 Jun 2014 01:48:09 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 4997728AE for ; Tue, 10 Jun 2014 01:48:09 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id uz6so1979227obc.24 for ; Mon, 09 Jun 2014 18:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=z/+NqzMpDMLWDRuaLkvElrovvKwlibEuMIPooBjgZJw=; b=hKlxJZV+va0CY6GkqtJDoDW/K+VyS/VUymJFIZbOfkOxFOeKUGeVySl70XAgAYQWw4 XkzOpiPuj/FQ5K7ltsGVLaW8xkOmLXC6cGt3lsxVshuXOQZydLhZjtT1A0PvlH0l3cMp 9wE5NOYvP/52OYuWPyQklxuBKN7+jpau6Yv/7tkaM/rdibIS7GW55yC/RolW3ZMPMYew 90Rb/9VpL3voNurEYZTEx6rXwzQTfcW9nuyBc9/cEghoixWZV2TCNYbYRxZIbErUtY30 BEvYQdFBj3BAeTPyzMOvBKjDxQznciRx/cCfuzpXfWF7FFY6ZFIuL5S5NQKMqTK2pKT1 v7vA== MIME-Version: 1.0 X-Received: by 10.60.62.174 with SMTP id z14mr13018369oer.61.1402364888420; Mon, 09 Jun 2014 18:48:08 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 9 Jun 2014 18:48:08 -0700 (PDT) Date: Mon, 9 Jun 2014 21:48:08 -0400 Message-ID: Subject: abi::__cxa_demangle provides invalid result on non-mangled symbols From: Ryan Stone To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 01:48:09 -0000 abi::__cxa_demangle is giving me an invalid result if I pass it a symbol that is not mangled. This is causing me problems as in my application, I'm getting symbol names from libelf and have no way of know a priori whether a symbol is mangled or not. The sample program below demonstrates the problem. I note that __cxa_demangle seems to work correctly on symbols that start with an underscore, so I guess that I can use that as a workaround, but it would be nice if this worked without hackery (plus I'm not at all confident that all mangled symbols must start with an underscore). #include #include #include int main(int argc, char **argv) { const char *symbol; char *demangled; size_t len; int status; if (argc != 2) { fprintf(stderr, "Usage: %s \n", argv[0]); return (1); } symbol = argv[1]; len = 0; status = 0; demangled = abi::__cxa_demangle(symbol, NULL, &len, &status); printf("__cxa_demangle(\"%s\") = \"%s\", status=%d\n", symbol, demangled, status); return (0); } [rstone@rstone-server demangle]uname -a FreeBSD rstone-server 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r254461+992b524(server_config): Thu May 22 22:19:47 EDT 2014 root@rstone-server:/usr/obj/usr/src/sys/STOCK amd64 [rstone@rstone-server demangle]./demangle memcmp __cxa_demangle("memcmp") = "unsigned long", status=0 [rstone@rstone-server demangle]./demangle _start __cxa_demangle("_start") = "(null)", status=-2 [rstone@rstone-desktop shm]uname -a Linux rstone-desktop 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [rstone@rstone-desktop shm]./demangle __cxa_demangle("memcmp") = "(null)", status=-2 From owner-freebsd-toolchain@FreeBSD.ORG Tue Jun 10 02:44:38 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 177B1CA for ; Tue, 10 Jun 2014 02:44:38 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (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 CDBF92CC3 for ; Tue, 10 Jun 2014 02:44:37 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id x3so1578193qcv.26 for ; Mon, 09 Jun 2014 19:44:36 -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=gJIc6OjtYrPcA0IAeF5fVrRm2H8zQSA71Rl+Qo/iSb8=; b=rH6wddpGCo4RoL+Pw5DEJslqYIuw4KJwWrfe+wiKBmCjx/exOCrhroRqXDvlEZNPap 8on9dpN/4tts3A6fz8cCEEANxr62zA9JwkHVRQ4jNU1teIPs01qURmIgpdXRi4ULMmhV raZcDCh3qMW1hHmL/E161ITiyW/aeA/tzfO/P+fqhxQ4FHDlHufR0emvHxzd+F7VMANo KzrWlR89cVwVJsSeHgdSay/6RR8+rHKNt9TSdh0LfA7lpXjREtNT/gk3Z70+IixY/y3M NnYm1FsjW5dAeUglhVVV109NqJld2LELLhdfCTifUrbECIWiuux6MZCj5jUsxMuZcxzv veFA== MIME-Version: 1.0 X-Received: by 10.140.48.1 with SMTP id n1mr9091407qga.107.1402368276857; Mon, 09 Jun 2014 19:44:36 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.49.239 with HTTP; Mon, 9 Jun 2014 19:44:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 22:44:36 -0400 X-Google-Sender-Auth: rY7ju9JbUzOLuvGwTgvQMhIjzKc Message-ID: Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: Ed Maste To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 02:44:38 -0000 On 9 June 2014 21:48, Ryan Stone wrote: > abi::__cxa_demangle is giving me an invalid result if I pass it a > symbol that is not mangled. This is causing me problems as in my > application, I'm getting symbol names from libelf and have no way of > know a priori whether a symbol is mangled or not. I had the same issue in LLVM, and as hacky as it seems, the solution is to check that the name starts with "_Z" before passing it to __cxa_demangle. For reference the LLVM review for the change is here: http://reviews.llvm.org/D2552 I didn't get around to testing it on Linux; since you have a test application ready it would be interesting to see the result of __cxa_demangle("f") there. From owner-freebsd-toolchain@FreeBSD.ORG Tue Jun 10 03:01:51 2014 Return-Path: Delivered-To: freebsd-toolchain@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 48CAB6DB; Tue, 10 Jun 2014 03:01:51 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (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 07C9A2EBB; Tue, 10 Jun 2014 03:01:50 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id j17so3310064oag.39 for ; Mon, 09 Jun 2014 20:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fii2aP0Y9j7hLKnKnmb9aWIS9qL3b3Iyuwhzk1B8fJY=; b=dgmxddjqKAK2RCCibAQNnugpfoEnvePokHsTKdmcrOXvbEd5KTtQNvKXger74BNk4I gGNcBlP8qZYiVPxaAFPLuwPw9mfSeMQC4XKxRxbbUaWfCJ2LcK39r+Hw1/1d6qgjzcw/ k7Qrb30spTETz/GHkxMqGncaxQsdqbTH1WUMtRQm3Q2nn2bKVXCT+I6trPtL+I1yRZlr gIXTH/iEY1BPJ7xVWKqot7UwqmN4DJtLtY/wt1Vt2CETJ+bTaVMCyxv65ZJzBzUlmmT9 02dkt8vzt0umdh4jFQazGFbnsGTiRLhsgwLcBFyOheByBjvooE0DdPjtKDlrz7U+GWJ+ l4EA== MIME-Version: 1.0 X-Received: by 10.60.45.130 with SMTP id n2mr30157121oem.12.1402369310218; Mon, 09 Jun 2014 20:01:50 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 9 Jun 2014 20:01:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 23:01:50 -0400 Message-ID: Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: Ryan Stone To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:01:51 -0000 On Mon, Jun 9, 2014 at 10:44 PM, Ed Maste wrote: > On 9 June 2014 21:48, Ryan Stone wrote: >> abi::__cxa_demangle is giving me an invalid result if I pass it a >> symbol that is not mangled. This is causing me problems as in my >> application, I'm getting symbol names from libelf and have no way of >> know a priori whether a symbol is mangled or not. > > I had the same issue in LLVM, and as hacky as it seems, the solution > is to check that the name starts with "_Z" before passing it to > __cxa_demangle. > > For reference the LLVM review for the change is here: > http://reviews.llvm.org/D2552 > > I didn't get around to testing it on Linux; since you have a test > application ready it would be interesting to see the result of > __cxa_demangle("f") there. You're right, it is a problem in Linux: [rstone@rstone-desktop shm]./demangle f __cxa_demangle("f") = "float", status=0 [rstone@rstone-desktop shm]./demangle i __cxa_demangle("i") = "int", status=0 [rstone@rstone-desktop shm]./demangle m __cxa_demangle("m") = "unsigned long", status=0 [rstone@rstone-desktop shm]./demangle main __cxa_demangle("main") = "(null)", status=-2 The GNU version is just a little smarter about erroring out properly on "main", but there's nothing stopping anybody from using a function called "f" so I'll use your recommended workaround. Thanks. From owner-freebsd-toolchain@FreeBSD.ORG Tue Jun 10 06:58:36 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B223BE19; Tue, 10 Jun 2014 06:58:36 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E3582114; Tue, 10 Jun 2014 06:58:35 +0000 (UTC) Received: from [192.168.0.96] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s5A6wHYF051813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jun 2014 06:58:22 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: David Chisnall In-Reply-To: Date: Tue, 10 Jun 2014 07:38:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> References: To: Ed Maste X-Mailer: Apple Mail (2.1874) Cc: freebsd-toolchain@freebsd.org, Ryan Stone X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:58:36 -0000 On 10 Jun 2014, at 03:44, Ed Maste wrote: > I had the same issue in LLVM, and as hacky as it seems, the solution > is to check that the name starts with "_Z" before passing it to > __cxa_demangle. >=20 > For reference the LLVM review for the change is here: > http://reviews.llvm.org/D2552 >=20 > I didn't get around to testing it on Linux; since you have a test > application ready it would be interesting to see the result of > __cxa_demangle("f") there. If you know that the thing that you are demangling is a symbol name, = then you can use the _Z check, which isn't really a hack - it's a marker = added to identify C++ symbols. Note that, if you're writing portable = code, you need to remember that some systems prepend an underscore to = all compiler-generated symbols, so you may also need to check for __Z = and trim the leading _. The __cxa_demangle() function has to handle things that are not just = symbols (types and so on) and so can't do this test itself. Its most = common use is generating a human-friendly error for an uncaught = exception, where it is just parsing a type encoding. The demangler that we ship is from libelftc. It also fails on a number = of C++11 types and doesn't handle some complex template cases. =20 David From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 02:43:41 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C094F92; Wed, 11 Jun 2014 02:43:41 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCD82D59; Wed, 11 Jun 2014 02:43:41 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:6415:be35:5fc5:314d] (unknown [IPv6:2601:9:8280:426:6415:be35:5fc5:314d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 125FA34A9E1; Tue, 10 Jun 2014 19:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1402454620; bh=t7bNdmCwhwl+flintfaSHw46BEaPE4fcYK1Yi7Lw65s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dCVx/LqOmtAov6B38dvUs64Cy1/O7H05Ei0w/lIKz2A54b64xOlbX3jDWf2eDGmJ+ ksvpJL3U5SczRvEK7+ydsAeVLvQ7ldlyfWVb1WVfQVEaza+JiGkALTFlnDbyV2Q83P Qxy1/SG3hY0R7h7kX9UvMUNwRp9Xibv08WDBHsww= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: Rui Paulo In-Reply-To: Date: Tue, 10 Jun 2014 19:43:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-toolchain@freebsd.org, Ryan Stone X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:43:41 -0000 On Jun 9, 2014, at 19:44, Ed Maste wrote: > I had the same issue in LLVM, and as hacky as it seems, the solution > is to check that the name starts with "_Z" before passing it to > __cxa_demangle. This is what I also did for libproc. -- Rui Paulo From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 12:31:00 2014 Return-Path: Delivered-To: freebsd-toolchain@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 2210F99A; Wed, 11 Jun 2014 12:31:00 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 3D0E921F3; Wed, 11 Jun 2014 12:30:59 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id n15so4764660lbi.19 for ; Wed, 11 Jun 2014 05:30:57 -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=WeUaqeH1hlW7ahbngi0itQv2+pN0GBUK2bc1lEnWMqc=; b=GZQruKrh4yLsu1O4GQBTMcMnXNlR7DEEoujJWkY9IbAxqRoJ3hcj92q/C+i/F7oQLn vHYAu34agtXBpN3/QZRzLa8X/7J+kW4tu087kWK9z571GhGExJSzib57pWu/RmbnlwTm gzDou8CBI5JcjIu8jSD0h0wej57GK2D4R4MT9pyLeSLIzgxFzRgM3bdWZ9eStg14tkHq RFJf/NCdqxGn58+Ituy7mRNym/fgUBzzVCPQBUsm4KSxZ+VFVlqGF5BP1VPwU/4K1Jtc A0wMioVYOcKwz+P85uN11fX+PoZIBPeY5+RkodQOIuvDAleOHnLSFSIYCTdiCPov7KFa bV1A== X-Received: by 10.112.34.210 with SMTP id b18mr11326242lbj.42.1402489857129; Wed, 11 Jun 2014 05:30:57 -0700 (PDT) Received: from localhost (s83-179-26-16.cust.tele2.se. [83.179.26.16]) by mx.google.com with ESMTPSA id lq20sm24733095lbb.24.2014.06.11.05.30.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Jun 2014 05:30:56 -0700 (PDT) Sender: Kai Wang Received: from localhost.localdomain ([127.0.0.1] helo=localhost.my.domain) by localhost with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Wuhg6-0000j1-Gl; Wed, 11 Jun 2014 14:30:54 +0200 Received: (from kaiw@localhost) by localhost.my.domain (8.14.5/8.14.5/Submit) id s5BCUsPg002790; Wed, 11 Jun 2014 14:30:54 +0200 (CEST) (envelope-from kaiw@FreeBSD.org) X-Authentication-Warning: localhost.my.domain: kaiw set sender to kaiw@FreeBSD.org using -f Date: Wed, 11 Jun 2014 14:30:54 +0200 From: Kai Wang To: David Chisnall Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols Message-ID: <20140611123054.GA2777@soulhacker> References: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ryan Stone , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:31:00 -0000 On Tue, Jun 10, 2014 at 07:38:19AM +0100, David Chisnall wrote: > On 10 Jun 2014, at 03:44, Ed Maste wrote: > > > I had the same issue in LLVM, and as hacky as it seems, the solution > > is to check that the name starts with "_Z" before passing it to > > __cxa_demangle. > > > > For reference the LLVM review for the change is here: > > http://reviews.llvm.org/D2552 > > > > I didn't get around to testing it on Linux; since you have a test > > application ready it would be interesting to see the result of > > __cxa_demangle("f") there. > > If you know that the thing that you are demangling is a symbol name, then you can use the _Z check, which isn't really a hack - it's a marker added to identify C++ symbols. Note that, if you're writing portable code, you need to remember that some systems prepend an underscore to all compiler-generated symbols, so you may also need to check for __Z and trim the leading _. > > The __cxa_demangle() function has to handle things that are not just symbols (types and so on) and so can't do this test itself. Its most common use is generating a human-friendly error for an uncaught exception, where it is just parsing a type encoding. > > The demangler that we ship is from libelftc. It also fails on a number of C++11 types and doesn't handle some complex template cases. Hi David, If possible, could you list a few examples that the demangler can not handle? Maybe we can fix this in libelftc and merge it back later. Thanks, Kai From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 12:41:31 2014 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DE71A3; Wed, 11 Jun 2014 12:41:31 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9E322F2; Wed, 11 Jun 2014 12:41:27 +0000 (UTC) Received: from [192.168.0.96] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s5BCfMRh064603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jun 2014 12:41:24 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: David Chisnall In-Reply-To: <20140611123054.GA2777@soulhacker> Date: Wed, 11 Jun 2014 13:41:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <281D8767-7B24-4B58-8669-CF60C597E58E@FreeBSD.org> References: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> <20140611123054.GA2777@soulhacker> To: Kai Wang X-Mailer: Apple Mail (2.1874) Cc: Ryan Stone , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:41:31 -0000 On 11 Jun 2014, at 13:30, Kai Wang wrote: > On Tue, Jun 10, 2014 at 07:38:19AM +0100, David Chisnall wrote: >> On 10 Jun 2014, at 03:44, Ed Maste wrote: >>=20 >>> I had the same issue in LLVM, and as hacky as it seems, the solution >>> is to check that the name starts with "_Z" before passing it to >>> __cxa_demangle. >>>=20 >>> For reference the LLVM review for the change is here: >>> http://reviews.llvm.org/D2552 >>>=20 >>> I didn't get around to testing it on Linux; since you have a test >>> application ready it would be interesting to see the result of >>> __cxa_demangle("f") there. >>=20 >> If you know that the thing that you are demangling is a symbol name, = then you can use the _Z check, which isn't really a hack - it's a marker = added to identify C++ symbols. Note that, if you're writing portable = code, you need to remember that some systems prepend an underscore to = all compiler-generated symbols, so you may also need to check for __Z = and trim the leading _. >>=20 >> The __cxa_demangle() function has to handle things that are not just = symbols (types and so on) and so can't do this test itself. Its most = common use is generating a human-friendly error for an uncaught = exception, where it is just parsing a type encoding. >>=20 >> The demangler that we ship is from libelftc. It also fails on a = number of C++11 types and doesn't handle some complex template cases. =20= >=20 > Hi David, >=20 > If possible, could you list a few examples that the demangler can not > handle? Maybe we can fix this in libelftc and merge it back later. Your best reference for this is the libc++abi test suite: = http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_demangle.cpp= ?revision=3D208611&view=3Dmarkup New C++11 additions and template arguments that are forward references = are not very well handled. It would be great if there were any = improvements. It would also be good for libcxxrt if the demangler could avoid having = to allocate any memory except on the stack, as one of the places where = it's used is in reporting out-of-memory conditions. David From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 18:53:23 2014 Return-Path: Delivered-To: freebsd-toolchain@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 857DD858; Wed, 11 Jun 2014 18:53:23 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 A8BFB2846; Wed, 11 Jun 2014 18:53:22 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id w7so92521lbi.23 for ; Wed, 11 Jun 2014 11:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=XyHpVN1uLydaUxAjuDK1fPZd5lVfXMXq0rawcIqqNa0=; b=g+TGWPFID1cESnUC0EorbQqEKVIWdYokb7HY0x2mOQmY5B7GFRpoHiWU8f5hOCFZ2y n3Oo+0na/tnxuCO2rJl9fUQjkEFovjXGzQsUd+qBDg5H/tQkjXQ7VY8M8ipTBcakwSBy hc17wJiM9ZFmG3xo6aKBFm/XvHzPnrWII8eoW7g4azYMOA3GdoqfvpF5H/QRJubWkalh sH2TCCkTXUkJ9xikvbzQsFpNEj6kTf/B3EUzxPi/QopgjQCYpTqAp6xZRYujZDfDdiqg KEo8nbLFgYfU4iE5uHYFl0gGo+r/2++BAoVEQNZK/DRgRywyM/rP2lhid/04abxLwJxE GOAg== MIME-Version: 1.0 X-Received: by 10.152.10.40 with SMTP id f8mr2691165lab.75.1402512800426; Wed, 11 Jun 2014 11:53:20 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.73 with HTTP; Wed, 11 Jun 2014 11:53:20 -0700 (PDT) Date: Wed, 11 Jun 2014 11:53:20 -0700 X-Google-Sender-Auth: 7iH_fC4dER1xYk2-3F0q1VaNaFw Message-ID: Subject: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Craig Rodrigues To: freebsd-arch Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:53:23 -0000 Hi, Recently when trying to debug some coredumps in CURRENT from a userland process in the devel/libvirt port, I found that the gdb in base could not get a backtrace from the core file: http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html I needed to add to my /etc/src.conf WITH_LLDB=yes and compile and install lldb, which *could* analyze the coredump. I realize that gdb in base is on its way out the door, and that clang and lldb are the new world order. However, one of the main blockers for removing gdb from base is that there is no equivalent to kgdb in the lldb world. Is anyone working on a kernel lldb? When is it expected to be ready? Will something like it be ready by end of 2014? Even though this may not be an issue in the stable/10 branch, it would be nice to have a kernel lldb debugger ready by the next 10.1R if possible. -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 19:06:59 2014 Return-Path: Delivered-To: freebsd-toolchain@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 9AD0EF3E; Wed, 11 Jun 2014 19:06:59 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (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 4D4342990; Wed, 11 Jun 2014 19:06:59 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id w8so260200qac.8 for ; Wed, 11 Jun 2014 12:06:58 -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=EguKilh5TyDj2DU9IfVk6Jhb/uhhV92rolyFj7QuXVg=; b=A/82z0mdIitHJXCNN/xZ5gEdU+yY7t2QOPFK7Y2REN4DLLx34ITaVSuZWO6x7UAZFv 6Ploag9cuuEXfY1mmoZFOPzAEMWzpEMPTa7iIu3eB0+jVGGQVME3NfTS5/OuJFJ4rB/5 rPt8TFB36lkeZEcpDcZsZ/ulmJUigM5xLatr74O7Z3+DUTzZuA7LAiXwhsFl4Zbd/+of j2B+cRx0KtqDhOgWUFD0BjlYtUXKDNGqjC9xChPr93FBY3wYd25wrRBn6RfrGK3c0rrg XAf6TOtcrvyLdVY+KmA3gV2iA/Il9EuofqulT0MOMEvWUKZMyINIkIQlnGnIX1NZQC4x +rsQ== MIME-Version: 1.0 X-Received: by 10.224.16.139 with SMTP id o11mr9482535qaa.80.1402513618435; Wed, 11 Jun 2014 12:06:58 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.49.239 with HTTP; Wed, 11 Jun 2014 12:06:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jun 2014 15:06:58 -0400 X-Google-Sender-Auth: njK261991iNvNo05i5m8iv63YoE Message-ID: Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Ed Maste To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:06:59 -0000 On 11 June 2014 14:53, Craig Rodrigues wrote: > > Is anyone working on a kernel lldb? When is it expected to be ready? Kernel LLDB support is an ongoing Summer of Code project this year. I'm not sure it's feasible for 10.1 though. From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 19:31:20 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9297F77D; Wed, 11 Jun 2014 19:31:20 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CDDE2BE1; Wed, 11 Jun 2014 19:31:20 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c5cc:f189:593d:8554] (unknown [IPv6:2001:7b8:3a7:0:c5cc:f189:593d:8554]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1AF7C5C37; Wed, 11 Jun 2014 21:31:10 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C95AB983-3A47-4638-B540-03A1056D9D33"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Dimitry Andric In-Reply-To: Date: Wed, 11 Jun 2014 21:30:55 +0200 Message-Id: References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.2) Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:31:20 -0000 --Apple-Mail=_C95AB983-3A47-4638-B540-03A1056D9D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Jun 2014, at 20:53, Craig Rodrigues wrote: >=20 > Recently when trying to debug some coredumps in CURRENT from > a userland process in the devel/libvirt port, I found that the gdb in > base could not get a backtrace from the core file: >=20 > = http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606= .html Can you please post the output of the following? objdump -W /usr/local/sbin/libvirtd | head -Dimitry --Apple-Mail=_C95AB983-3A47-4638-B540-03A1056D9D33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlOYrn0ACgkQsF6jCi4glqNUeACfQyrdsQXUv+fGLy6b6OjhSm/d lU4AoJelryqilH+pDy2GWLBckl45JJmc =c6iW -----END PGP SIGNATURE----- --Apple-Mail=_C95AB983-3A47-4638-B540-03A1056D9D33-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 19:56:30 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CED2FF61; Wed, 11 Jun 2014 19:56:30 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 C62262ECD; Wed, 11 Jun 2014 19:56:29 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so137067lbj.17 for ; Wed, 11 Jun 2014 12:56:27 -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=FTxSneSce6s4taSh930jnBbfT0xTck8ic2udZd0dGvU=; b=MeL/VTIEis9Eq2PJyp7QFRjDc209pU469KuR1Jy6nEw78xRrh8TrjTExSRRIS78tyK oQInvdyF+8EAKRASPkEKhXnSI4xJbo9A1xfxw6gZiphC/9dBSXs/wuVvqFXVnirFAfuC R+sTCGrU1ZTBWlqkPmkAPDJLXjjjF2c823V0zUgi+p6BtKEFRudG30bX6gJkw0ErchK5 LT7wOsw8tl/MZe2pr49pppliJfqy5J2Nk9bVFwEanXeGthcmwTmsVGfnZ9mAB1i6QwLs AwNVSGkFtHC0o/LgFzyf2v5TqyPpVQGGjDHvJcWNfz6rYwtjhVtzw7Ac/Q8bpieiPYHc OmhQ== MIME-Version: 1.0 X-Received: by 10.112.130.229 with SMTP id oh5mr8276111lbb.49.1402516587680; Wed, 11 Jun 2014 12:56:27 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.73 with HTTP; Wed, 11 Jun 2014 12:56:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jun 2014 12:56:27 -0700 X-Google-Sender-Auth: WLSqG3F7Dxwhn581ArLQWJePWi4 Message-ID: Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:56:30 -0000 On Wed, Jun 11, 2014 at 12:30 PM, Dimitry Andric wrote: > On 11 Jun 2014, at 20:53, Craig Rodrigues wrote: >> >> Recently when trying to debug some coredumps in CURRENT from >> a userland process in the devel/libvirt port, I found that the gdb in >> base could not get a backtrace from the core file: >> >> http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html > > Can you please post the output of the following? > > objdump -W /usr/local/sbin/libvirtd | head > > -Dimitry > $ objdump -W /usr/local/sbin/libvirtd | head /usr/local/sbin/libvirtd: file format elf64-x86-64-freebsd The section .debug_aranges contains: Length: 92 Version: 2 Offset into .debug_info: 0 Pointer Size: 8 Segment Size: 0 -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 19:58:37 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3A2F113; Wed, 11 Jun 2014 19:58:37 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 E767D2EEF; Wed, 11 Jun 2014 19:58:36 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pn19so141529lab.20 for ; Wed, 11 Jun 2014 12:58:34 -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=/67wby0THGpy9/P6JH1jFCi0I+O1ACr7SLJXnBn0mB8=; b=XZGzkSL0Ykvs9lAK4H1vYpv7xrLV/reEspox1OYWzRx54ioy6KnbbKy/LsVP+OQhNZ dmJyugtX5akrYAvYqLTCU6iwz7wjCtAl4wVNqaydNh1uH5GGj7Fm7DaHlxhykUBmnW5i vcPoh83nsjizm/fBxp67TZzTjkGXAd9uZ/mKVNuEiE56+kL3AkF6kZvPCKfeoFF4HETS Jqn527qORTcHUOhSEY4LTlKZIoldZVrs1UyX0UWnsoFAc9sYmnEACjX7ZEhF3cNVgM7G R5x7RI14fLgHqJC/p7uOyOeMn9OJyHUDrP7HvD9qI5QQGStvqg29/Oa5OLj3N01Tur89 ikjQ== MIME-Version: 1.0 X-Received: by 10.112.130.229 with SMTP id oh5mr8282626lbb.49.1402516714721; Wed, 11 Jun 2014 12:58:34 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.73 with HTTP; Wed, 11 Jun 2014 12:58:34 -0700 (PDT) In-Reply-To: <33D37CFE-CA6B-4F89-9178-ACF2352CC6C5@bsdimp.com> References: <33D37CFE-CA6B-4F89-9178-ACF2352CC6C5@bsdimp.com> Date: Wed, 11 Jun 2014 12:58:34 -0700 X-Google-Sender-Auth: RMDgtj5UX5QJDIGFsaEwwTi-HcI Message-ID: Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Craig Rodrigues To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:58:37 -0000 On Wed, Jun 11, 2014 at 12:34 PM, Warner Losh wrote: > > Except for kgdb functionality, the gdb ports (both the 6.x and 7.x ones) work much better than the gdb in the tree. This may be a good stop-gap until lldb is ready. > > Warner > I installed devel/gdb which installs gdb762. When I tried to debug the corefile, I encountered the same problem which I saw in: http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 20:40:07 2014 Return-Path: Delivered-To: freebsd-toolchain@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 397865B1; Wed, 11 Jun 2014 20:40:07 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6028237C; Wed, 11 Jun 2014 20:40:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c5cc:f189:593d:8554] (unknown [IPv6:2001:7b8:3a7:0:c5cc:f189:593d:8554]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 398F05C37; Wed, 11 Jun 2014 22:40:03 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B9FB59A4-79B1-4144-ACE0-291B0AFCB25A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Dimitry Andric In-Reply-To: Date: Wed, 11 Jun 2014 22:39:49 +0200 Message-Id: <11764709-BB10-47C5-B537-5AC5A0A0E2E6@FreeBSD.org> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.2) Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:40:07 -0000 --Apple-Mail=_B9FB59A4-79B1-4144-ACE0-291B0AFCB25A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Jun 2014, at 21:56, Craig Rodrigues wrote: > On Wed, Jun 11, 2014 at 12:30 PM, Dimitry Andric = wrote: >> On 11 Jun 2014, at 20:53, Craig Rodrigues = wrote: >>>=20 >>> Recently when trying to debug some coredumps in CURRENT from >>> a userland process in the devel/libvirt port, I found that the gdb = in >>> base could not get a backtrace from the core file: >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606= .html >>=20 >> Can you please post the output of the following? >>=20 >> objdump -W /usr/local/sbin/libvirtd | head >>=20 >> -Dimitry >>=20 >=20 > $ objdump -W /usr/local/sbin/libvirtd | head >=20 > /usr/local/sbin/libvirtd: file format elf64-x86-64-freebsd >=20 > The section .debug_aranges contains: >=20 > Length: 92 > Version: 2 > Offset into .debug_info: 0 > Pointer Size: 8 > Segment Size: 0 Ah sorry, your objdump prints sections in a different order than mine. I was mainly interested in the DWARF version of debug information; maybe the way you built libvirt has caused it to contain DWARF4 instead of DWARF2. Can you post the complete objdump output instead, or post just the part under "The section .debug_info contains"? That should look similar to: The section .debug_info contains: Compilation Unit @ offset 0x0: Length: 59 Version: 4 Abbrev Offset: 0 Pointer Size: 4 [...] but with possibly another "Version:" line. -Dimitry --Apple-Mail=_B9FB59A4-79B1-4144-ACE0-291B0AFCB25A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlOYvqEACgkQsF6jCi4glqPEAACg9iqYRyH9cjMBDhAw/1/3ZI8F OZkAoJVMjiuem2mQ9N8ySy5KGd30Z9Qh =kX7z -----END PGP SIGNATURE----- --Apple-Mail=_B9FB59A4-79B1-4144-ACE0-291B0AFCB25A-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 20:53:42 2014 Return-Path: Delivered-To: freebsd-toolchain@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 EA890F01; Wed, 11 Jun 2014 20:53:42 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::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 9A366250B; Wed, 11 Jun 2014 20:53:42 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id k15so459434qaq.30 for ; Wed, 11 Jun 2014 13:53:41 -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:content-transfer-encoding; bh=k03J2+VevTGLQSWK3BxpZNERpIJhA8c+HP0yvv29Auw=; b=Y8sQhgxHaOUgLDy6z00vMGbg19UjHmRw9kWNlBaVhme2zkpbGGHusWtVM7vGVx2T5K hTop3oZIK1TU9F8T8x7zWpP49KArE1yEpI+ziadsxCgodafKDJX6RYvwYmy7ing+8IF2 xQs7BGrulCBFh5ws+4rpFXmqL0r2nwsuCwDHba/zVhryK2k0llm2xLz64IOd4ggES77R xt88HbGbeOXdpplo8b+U2rUfiw1ZfAXtjmywu2mTYmOyyQdHvfWyghI0LCqbIphVrZhc +/Ozze5ixj3oHHoHK8TKFBNLJTdHOD8BVUjoQepWVH42tSeBr+kMLyf0agi4vONTnpY/ F5cg== MIME-Version: 1.0 X-Received: by 10.229.220.197 with SMTP id hz5mr54963104qcb.9.1402520021483; Wed, 11 Jun 2014 13:53:41 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.49.239 with HTTP; Wed, 11 Jun 2014 13:53:41 -0700 (PDT) In-Reply-To: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> References: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> Date: Wed, 11 Jun 2014 16:53:41 -0400 X-Google-Sender-Auth: AbbszqL4ZY0k7PscuplUS2HVd5w Message-ID: Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: Ed Maste To: David Chisnall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-toolchain@freebsd.org, Ryan Stone X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:53:43 -0000 On 10 June 2014 02:38, David Chisnall wrote: > > If you know that the thing that you are demangling is a symbol name, then= you can use the _Z check, which isn't really a hack - it's a marker added = to identify C++ symbols. Note that, if you're writing portable code, you n= eed to remember that some systems prepend an underscore to all compiler-gen= erated symbols, so you may also need to check for __Z and trim the leading = _. Right, it just feels hackish to have to know this detail of the ABI. I think I'd like an explicit __cxa_demangle_symbol interface, or perhaps __cxa_is_mangled_symbol to query a string. > The __cxa_demangle() function has to handle things that are not just symb= ols (types and so on) and so can't do this test itself. Its most common us= e is generating a human-friendly error for an uncaught exception, where it = is just parsing a type encoding. My use, and I suspect Ryan's, is demangling symbols obtained from introspection interfaces like backtrace_symbols(3). In any case, our libelftc __cxa_demangle accepts strings that are neither symbols nor NTBS manglings, and can return a bogus demangled name for them. Of course, it's a mistake to rely on __cxa_demangle rejecting these for arbitrary input. From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 21:28:56 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A992E62 for ; Wed, 11 Jun 2014 21:28:56 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (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 378E228F7 for ; Wed, 11 Jun 2014 21:28:55 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y10so223552pdj.5 for ; Wed, 11 Jun 2014 14:28:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=m93boXdfh/qmG2iPsPngp/4xeXwSKhcZgvcx8HhEFAU=; b=btmMV9nS3Cm/lBN2CXBTbMrb/w6JlC/SFShhLh3XrjYSyScqBDVfQJkRA9kkAXNYad 5CzRQFzMew7WeXsfTZS98oN582Jk2Oux66/fEy2WqWF1yfCakPYATw+jmXwxC8tFp/33 j83QqArT0gx6arYkgy/EjuDtBhUEdM96VEE46nKnZBfeWxM5NZwNNpa4VV+rxEeBx9zu EHZHDwOwr4gHEgqNefVc2mGvjyQONme0hRgo1b3RyBr9Oo2rbnLPeAbKn9oHf0lpQ0C6 upWNungKVbtQV9OTl34jT0vKmCJrdL2PxVoyln/XWZxww1hKUByeEKnuf34b4OgD+duL 6ZYw== X-Gm-Message-State: ALoCoQnKoq4LkaIkG4MctcB3zSJkqJ2Y3FiOyV7SmeMn8hspZ4uqlbS8MzSLw77HLJrbbdlIVOFD X-Received: by 10.66.240.130 with SMTP id wa2mr15768891pac.73.1402515252675; Wed, 11 Jun 2014 12:34:12 -0700 (PDT) Received: from lgmac-cvenus.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id is5sm76471126pbb.8.2014.06.11.12.34.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 12:34:12 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_90641765-7931-4A5F-ABC6-B3746065B63A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Warner Losh In-Reply-To: Date: Wed, 11 Jun 2014 13:34:15 -0600 Message-Id: <33D37CFE-CA6B-4F89-9178-ACF2352CC6C5@bsdimp.com> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.2) Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 21:28:56 -0000 --Apple-Mail=_90641765-7931-4A5F-ABC6-B3746065B63A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 11, 2014, at 12:53 PM, Craig Rodrigues = wrote: > Hi, >=20 > Recently when trying to debug some coredumps in CURRENT from > a userland process in the devel/libvirt port, I found that the gdb in > base could not get a backtrace from the core file: >=20 > = http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606= .html >=20 > I needed to add to my /etc/src.conf WITH_LLDB=3Dyes > and compile and install lldb, which *could* analyze the coredump. >=20 > I realize that gdb in base is on its way out the door, and that > clang and lldb are the new world order. However, one of the > main blockers for removing gdb from base is that > there is no equivalent to kgdb in the lldb world. >=20 > Is anyone working on a kernel lldb? When is it expected to be ready? > Will something like it be ready by end of 2014? >=20 > Even though this may not be an issue in the stable/10 branch, > it would be nice to have a kernel lldb debugger ready by > the next 10.1R if possible. Except for kgdb functionality, the gdb ports (both the 6.x and 7.x ones) = work much better than the gdb in the tree. This may be a good stop-gap = until lldb is ready. Warner --Apple-Mail=_90641765-7931-4A5F-ABC6-B3746065B63A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTmK83AAoJEGwc0Sh9sBEA3bgP/A6pwOewyvMql3Kt5Q88qLvW ESl2hCAa161UB2X6bB7F/EYCewjO8oF/csSArM/C1dkos2MW4lT+Rx5I9LgVsiSj oXjpRR9xxg3X7T+XXsfdHDYhzZbEFeQCGW5Z/T5lje92te4ZX7GKEUUa//aG+q5a j5XScZIQWxT8/xxWYsJIVFzoZ00HHd+/py3dKuKCoqscXwDybWCpLXdRzHIGUVJ9 t3Mu40e8cCibN7gSOoKefJkch89G+Y3uyqvE5u2fylhnkFRE6QO+rC7Muc6X29Ce 03F34kTU0AUCAXcCG1b2oQ89eKzdb+1cZ4iIg6X3L6AXjJeYhzGDK94oNgpInEbQ Z/FW8xcbONOHphanNOhdtp/iKFmXzZuBrjA+fwNDanu97+85dMNtnQ2Giy/mSQ7K uu1rQOHuMdfP4e0CzP8ped6c7lnartt4C/zl/XUumaKfMz+dRpKb/zwb/ZiFVQB8 Ztl4kfXVAqnOwajL9rdYlIyAh7DWIYfCrE0BP/FrgheHjerdec7NjrWSE+1rsVdG Rz27bTIA6ozi+0m+G+k5MpGo7fo42JCfFAIn0jTH37uhRfX4OMwI1H0Q/Lh79+wT BQhHiiawVxoYQKgt6T/lPBQaASvtK6a6krZrzw8LUjVPURvT3c+TcNvODqSh8YnW gS3P7Qpalel2fkpMNPWf =BOZX -----END PGP SIGNATURE----- --Apple-Mail=_90641765-7931-4A5F-ABC6-B3746065B63A-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 22:18:22 2014 Return-Path: Delivered-To: freebsd-toolchain@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 5B257CE8; Wed, 11 Jun 2014 22:18:22 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 4C83E2D99; Wed, 11 Jun 2014 22:18:21 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id u10so216548lbd.38 for ; Wed, 11 Jun 2014 15:18:19 -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=GPVm7jEMxHf0KYpgUxAsFjmZuAkx7ksf9kG3WmyQvwE=; b=k1N/3uANxAc+spNp5vDmdmFAxq+gd2IZw9VxFhDuLwcaHfJpjKLpaHtZVngimJ3sJh F8WWIkk70WdabItpKJxOLePxDQ/8QMkxXXoXehnRaCMLzLd5VsGchDH21Xg4yIUi2Idp rSxMIRo3Ay7KnNMeszQ8C77HUI/A5R7zu6vpyGAVwxo/bKKNAwL1h7/eZPw+cMD6Uzoj 0cdC+chbHVKnczdP0ReCt7uIcGcsTGVdTQaeXVLy82Fl6YlratoSiD9hNucXObgWGPfR rH+hquo+JhG44mvIWTvwophD55+tSCWoG5oBJIhcHyC3KB6xYBFdXStVtcAkiYaWE1Pr xxIw== MIME-Version: 1.0 X-Received: by 10.152.87.136 with SMTP id ay8mr14195621lab.42.1402525099077; Wed, 11 Jun 2014 15:18:19 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.73 with HTTP; Wed, 11 Jun 2014 15:18:19 -0700 (PDT) In-Reply-To: <11764709-BB10-47C5-B537-5AC5A0A0E2E6@FreeBSD.org> References: <11764709-BB10-47C5-B537-5AC5A0A0E2E6@FreeBSD.org> Date: Wed, 11 Jun 2014 15:18:19 -0700 X-Google-Sender-Auth: 4PGegnxkn4bzMBk71Nx3uVWNz9A Message-ID: Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:18:22 -0000 On Wed, Jun 11, 2014 at 1:39 PM, Dimitry Andric wrote: > Ah sorry, your objdump prints sections in a different order than mine. > I was mainly interested in the DWARF version of debug information; maybe > the way you built libvirt has caused it to contain DWARF4 instead of > DWARF2. > > Can you post the complete objdump output instead, or post just the part > under "The section .debug_info contains"? That should look similar to: Here is the full output of objdump -W /usr/local/sbin/libvirtd: http://people.freebsd.org/~rodrigc/libvirtd_objdump.txt -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 4 14:39:00 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85DB4FD7; Fri, 4 Jul 2014 14:39:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0444208D; Fri, 4 Jul 2014 14:38:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s64EcpAT011045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 17:38:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s64EcpAT011045 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s64EcoWX011044; Fri, 4 Jul 2014 17:38:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jul 2014 17:38:50 +0300 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: Intercepting calls in PIC mode Message-ID: <20140704143850.GH93733@kib.kiev.ua> References: <53B69A43.3000100@ivan-labs.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JBmVoN0GeLJFe550" Content-Disposition: inline In-Reply-To: <53B69A43.3000100@ivan-labs.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: toolchain@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:39:00 -0000 --JBmVoN0GeLJFe550 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 04, 2014 at 04:12:51PM +0400, Ivan A. Kosarev wrote: > Hello, >=20 > Consider the following: >=20 > --- > #include > #include >=20 > extern "C" void* memset(void *block, int c, size_t size) > __attribute__((weak, alias("__int_memset"), visibility("default"))); >=20 > extern "C" __attribute__((visibility("default"))) > void* __int_memset(void *block, int c, size_t size) { > puts("Hello"); > return NULL; > } >=20 > int main() > { > void *(*F)(void *b, int c, size_t len) =3D memset; > char a[5]; > memset(a, 0, sizeof(a)); > F(a, 0, sizeof(a)); > return 0; > } > --- >=20 > It intercepts the memset() calls without issue on both x86-64 FreeBSD=20 > 9.2 and Linux. However, with the -fPIC option specified in the cc's=20 > command line, only the first (direct) call work on FreeBSD, but not the= =20 > second (indirect) one. Note is that on Linux both the calls are=20 > intercepted--no matter whether the -fPIC option is specified or not. Your example is rather convoluted, I will try to explain below why. First, I am sure that C99 does not allow to override the semantic of the standard-defined functions. That said, a call to memset(3) can be inlined by a compiler, so there could be nothing to intercept. Second, FreeBSD implementation of the weak ELF symbols is non-compliant. The dynamic linker prioritizes non-weak symbols over the weak. This at least explains why your code snippet does not segfaults: the memset(3) =66rom libc is not interposed by your memset() implementation, so libc can at least initialize itself. If you remove weak attribute from the memset(), debug version of libc fails with assertions in jemalloc, while normal build just segfaults. That said, there are also differences in the static linker behaviour. Clang generates the following code to obtain the address of the memset(3) function: movq memset@GOTPCREL(%rip), %rsi The in-tree ld from binutils 2.17.redhat generates the R_X86_64_GLOB_DAT relocation to fill the GOT entry for the memset symbol. Processor of the GLOB_DAT in the rtld-elf always starts the lookup of the requested symbol in the object next from main. For your code, this means libc is searched for memset to fill the slot, and you get a libc symbol. The ld from the stock build of binutils 2.24, on the other hand, does not generate a relocation at all, it resolves memset internally from the same object file and fills the offset directly into instruction. I.e., when the program is linked with new ld, it works as you intend. This is probably the reason why it worked for you on Linux. I am not sure what conclusion could be made from the story I just told you. Might be, 'do not try to interpose std C functions' and 'put interposers into the LD_PRELOADed objects' ? --JBmVoN0GeLJFe550 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTtrx6AAoJEJDCuSvBvK1B42YP/21lu2qUek1o0EsT/ePohCSX f32abyLwhhZkG1RGlpoeHvOtGBsJhZ2xSHFVgLd+zMbvJ2Yx4H9U+7+zcybSGTB3 J9g2FmkOH4/SXN+SkSijt/T8gVz+JKdcb8nB/EhPcZBxVBrvv7VSs3e62yFLC7aJ bil4OkAvEqQvi0w7Qw0Jj2IDjSgqIQkBg5l+rBeayCS695oSxsgIFXz0+Nz8jhqY U0VizVeLwYuUbczqsvItoyMQM/JTKyuqEb/yGK/iMR0bNoR85wyp4nM+bawYmjkr abF2fGmoshDafbAemDpWc2KCGds76O+RBtpGTY5nIKt/BmgRw8gBHlCzkA5DRjjU uEAG5c4M23IST0G1u44feuk6k+6fcxmNgPX+H/k6iTA01mNlfMI2jIaoC6RvIUKL MHtQijVZXtnrlgDkgVaE/8lYz+SeK7q38GmD72f/s7LIBh/UVSo9NCzKe1MAEGe2 +Nqhz34Hby5L+bsYKVSS4O8EeP04qH9Y21Pa7YXWzAA+ynsGcShBl/H//L/gX55g v2JTRAAPjkJ5MB8ypiOig0KxE1fB33GNmK193eYqWOCK50wL6dYW9zpaVf2U1lRP WFM2aUBK6iJQqxSE81NhzZpIlHVWlvJWoA2oG9Eyl8fZgsyocOjrKynyz4ZBiIiA kAmd9HTGfvPuxzjo8ixp =GF6d -----END PGP SIGNATURE----- --JBmVoN0GeLJFe550-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jul 7 19:27:17 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 066E278E; Mon, 7 Jul 2014 19:27:17 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 56F8027EC; Mon, 7 Jul 2014 19:27:16 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id l4so3266430lbv.28 for ; Mon, 07 Jul 2014 12:27:14 -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=b+/FFFsR8BRBG/0W9ny0b52RXMMUiAX68WMH/lb4w0g=; b=xcS+W4+hX6RYN0gZ6dfzi8ghWMnqrmjL1MIypnPeFLVJCGzBlsD7gE6y0PMYZbA6FP bK8tEjmjf5WWzqvbfJ7Hwhp2K+/UffDtFYNamkIgmINYTz7yBj9uncLLEpZVTf2vXM65 1/6NLCvJ8GoF8UIbQl0DHC254L0tz9laXRlg36momWTig7Jdy0/Z3jdsbTPfyakpHk7B fSdz43xZEKOjGvjDI2uF8CS/ZBFQ29PZe2SzigPWxxmvz1gii5vzZKdIXER/u0N2CMid Fil5UiwfinA9TdPQ9ASN+BgcCFWVjzaoBsDO29/GKFWGgPSbQlJ/cocKWUXXIfKBp/Hs oTBA== MIME-Version: 1.0 X-Received: by 10.152.204.102 with SMTP id kx6mr24963582lac.32.1404761234181; Mon, 07 Jul 2014 12:27:14 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.71 with HTTP; Mon, 7 Jul 2014 12:27:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 12:27:14 -0700 X-Google-Sender-Auth: WMe1-smUK4mJnJHtX3wKFg9oa5g Message-ID: Subject: Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming? From: Craig Rodrigues To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:27:17 -0000 Ed, Can we enable WITH_LLDB=yes by default in CURRENT only? It took me a while to figure out that I needed to build/install lldb to debug some of my coredumps in CURRENT. I realize that things are in motion with respect to the toolchain, but it is annoying that in CURRENT, we have a debugger in the base system that cannot debug userland cores properly. I realize that things are in motion with respect to the toolchain, but this will help. I really hope that the Summer of Code project to implement kernel debugging support for lldb reaches completion and we can finally remove our ancient gdb from base (at least in CURRENT). Thanks. -- Craig On Wed, Jun 11, 2014 at 11:53 AM, Craig Rodrigues wrote: > Hi, > > Recently when trying to debug some coredumps in CURRENT from > a userland process in the devel/libvirt port, I found that the gdb in > base could not get a backtrace from the core file: > > > http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html > > I needed to add to my /etc/src.conf WITH_LLDB=yes > and compile and install lldb, which *could* analyze the coredump. > > I realize that gdb in base is on its way out the door, and that > clang and lldb are the new world order. However, one of the > main blockers for removing gdb from base is that > there is no equivalent to kgdb in the lldb world. > > Is anyone working on a kernel lldb? When is it expected to be ready? > Will something like it be ready by end of 2014? > > Even though this may not be an issue in the stable/10 branch, > it would be nice to have a kernel lldb debugger ready by > the next 10.1R if possible. > > -- > Craig >