From owner-freebsd-hackers@freebsd.org Sun Oct 29 00:36:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D1CE52640; Sun, 29 Oct 2017 00:36:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id EE25822B0; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6CDA0176E; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) Subject: Re: Crypto overhaul To: Poul-Henning Kamp , Benjamin Kaduk Cc: Ben Laurie , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 20:36:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <24228.1509196559@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:36:02 -0000 On 10/28/2017 09:15, Poul-Henning Kamp wrote: > -------- > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > >> I would say that the 1.1.x series is less bad, especially on the last count, >> but don't know how much you've looked at the differences in the new branch. > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > FreeBSD has higher ambitions. > I'm curious about your thoughts on LibreSSL as a possible option. From owner-freebsd-hackers@freebsd.org Sun Oct 29 00:54:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A55EBE52F2F for ; Sun, 29 Oct 2017 00:54:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-119.reflexion.net [208.70.210.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467032F39 for ; Sun, 29 Oct 2017 00:54:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14396 invoked from network); 29 Oct 2017 00:54:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 00:54:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 28 Oct 2017 20:54:29 -0400 (EDT) Received: (qmail 6974 invoked from network); 29 Oct 2017 00:54:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 00:54:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 77492EC8676; Sat, 28 Oct 2017 17:54:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: Date: Sat, 28 Oct 2017 17:54:27 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:54:36 -0000 Hello Justin > On 2017-Oct-28, at 5:03 PM, Justin Hibbits = wrote: >=20 >> On Oct 28, 2017 17:08, "Mark Millard" wrote: >> powerpc64 and powerpc have very different stack handling >> rules for FreeBSD. As an example, powerpc does not require >> red-zones for signal handling in the kernel but powerpc64 >> does. >>=20 >> For lib32 support, what ABI is the powerpc code supposed >> to follow in the powerpc64 environment? What style of >> stack handling (and related register usage) is supposed >> to be in use? If it is distinct from powerpc native's >> ABI, what documentation should be looked at for the ABI? >=20 > PowerPC via lib32 should be using the 32-bit svr4 ABI. If you see any = discrepancy in that, it's a bug that needs fixed. Then I expect that the reason that devel/powerpc64-gcc based buildworld's make a lib32 that fails in code that is from /usr/lib32/crtbeginS.o is because /usr/lib32/crtbeginS.o ends up not having the right ABI involved and, so, misuses at least one register. (I've not worked out if there is any special transition from one ABI to the other (and later back) that is needed vs. not. But the red-zoning for powerpc64 should be more than sufficient for powerpc code that does not require it.) An interesting point is: (all on a powerpc64 FreeBSD head -r324071 system) # clang -dumpmachine -m32 powerpc-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine -m32 powerpc64-unknown-freebsd12.0 # gcc7 -dumpmachine -m32 powerpc64-portbld-freebsd12.0 # clang -dumpmachine powerpc64-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine powerpc64-unknown-freebsd12.0 # gcc7 -dumpmachine powerpc64-portbld-freebsd12.0 (But I'm not sure that these always reflect ABI variations in code generated.) I wonder if for gcc it takes a separate compiler to have powerpc-unknown-freebsd12.0 (intending to imply the FreeBSD 32-bit ABI is in use). bugzilla 206123 should probably have notes added about the probable ABI mismatch in /usr/lib32/crtbeginS.o. I may add this whole message but someone with better background information may able to submit more specific material. At this point I do not know how to control what ABI code is generated by devel/powerpc64-gcc in what becomes /usr/lib32/crtbeginS.o (or how other code interfaces with crtbeginS.o code). Its been a long time since I tried other gcc variations but all of them had the issue when I did try. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Oct 29 00:04:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47CE7E518D0; Sun, 29 Oct 2017 00:04:01 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFC8B14B0; Sun, 29 Oct 2017 00:04:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id p184so10957947lfe.12; Sat, 28 Oct 2017 17:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFBzB5yRggvmXSDA4i1Qx52O0bkv2bZ/nYuU+euMvgk=; b=fU3+b3N/Gmo/dkK922Q1iee9G1TFAsJEKAosUB1dunBsi8tDtd1oTyNATL4GCsFdn6 P5k9dGpI2aCYUGId0nxPbGHP0N6VyXf1yPc3aJMp97eqwldhLi2y7BGSYvLjKHS5x3Kj mitcpvoAoXk6rS0OECw5oldobLe11Neq/EKJzLQ01qOmt9CGfrpQgCk2VUI/zt8cne/G sbqSU+wFWv4+07OzU3rfFHMbhzT/v3hE5PhMfVevLqL3qZqpJbeJEKtnDyEjeTVmHt3b jXFwGfy1vqTIBHXFzxJ7neO+6a07GPI4xLXoWKGa792MmmzvJ80HgfNhJbfYuH6BOb+a 9N6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UFBzB5yRggvmXSDA4i1Qx52O0bkv2bZ/nYuU+euMvgk=; b=FBQzTkqmwfvLrfvNotlchJdip5FsGEzQXSGpoYBzZYM9ILMBiG9YwAAXtl6mNlVOkS xqO4g82KTsm232MZ4I5i13w21DwJfWdzFJy4KQLKExJva8oybokpMDIRR4FwjX7O3W10 gqqeSLbky8FKyiVWM+p6jZ3u3/hU2+q70ihETrQ6f1QQeqj/XJUh3BtBFYLcUJuJ9tsS bl3/bsoE9OwGXiu0VH9g3koBf61iK3pzWkwT7L4aASmdXNm+97/VK/L08Q3tSD8rZNCx aCfqvdzn5uxNdnL9MoVT8AVRUQc7HeJtpMufB0DaKMV+IBFSDtNvthsQT+9KTsUZoKHl x1VA== X-Gm-Message-State: AMCzsaUzEzqIxw4C/lCb5DLEwYQ20a/CswcN/CKAs8VHp7AwZCj0ja6u 17GOeILwwqi0KEJIb17AMSdTGymIG1id53MIU7A= X-Google-Smtp-Source: ABhQp+QQv5zVIkFek73MYXAU4RowfgEYqOlg6zKRWubY+fePD+NzHFjRLlACqPp1uakSFPO/9e5b+6wWQRoH6tf/HvM= X-Received: by 10.46.93.137 with SMTP id v9mr1796791lje.39.1509235438668; Sat, 28 Oct 2017 17:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.86.7 with HTTP; Sat, 28 Oct 2017 17:03:57 -0700 (PDT) Received: by 10.46.86.7 with HTTP; Sat, 28 Oct 2017 17:03:57 -0700 (PDT) In-Reply-To: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> From: Justin Hibbits Date: Sat, 28 Oct 2017 19:03:57 -0500 Message-ID: Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? To: Mark Millard Cc: FreeBSD PowerPC ML , freebsd-hackers X-Mailman-Approved-At: Sun, 29 Oct 2017 06:16:38 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:04:01 -0000 Hi Mark On Oct 28, 2017 17:08, "Mark Millard" wrote: powerpc64 and powerpc have very different stack handling rules for FreeBSD. As an example, powerpc does not require red-zones for signal handling in the kernel but powerpc64 does. For lib32 support, what ABI is the powerpc code supposed to follow in the powerpc64 environment? What style of stack handling (and related register usage) is supposed to be in use? If it is distinct from powerpc native's ABI, what documentation should be looked at for the ABI? === Mark Millard markmi at dsl-only.net PowerPC via lib32 should be using the 32-bit svr4 ABI. If you see any discrepancy in that, it's a bug that needs fixed. - Justin From owner-freebsd-hackers@freebsd.org Sun Oct 29 06:23:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFBF9E5AC54 for ; Sun, 29 Oct 2017 06:23:43 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E6C36D729 for ; Sun, 29 Oct 2017 06:23:42 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TJPf1w00B0HtmFq01JPfyY; Sun, 29 Oct 2017 06:23:39 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=2rVjqWD_AAAA:8 a=mDV3o1hIAAAA:8 a=fjI6oOUNAAAA:8 a=e5mUnYsNAAAA:8 a=NEAV23lmAAAA:8 a=Aziwk6T4AAAA:8 a=Ye9q-bpsAAAA:8 a=Vt2AcnKqAAAA:8 a=uj8X_y5MAAAA:8 a=5x2gbUjwxCsc-tyLeXgA:9 a=QEXdDO2ut3YA:10 a=kZDNUv_x1BAA:10 a=Zb1NnzInM5wA:10 a=mhBgT-Iy8DAA:10 a=7MtbkP0eYeQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=_FVE-zBwftR9WsbkzFJk:22 a=CraPrAVN91dFfRf5Enq8:22 a=Vxmtnl_E_bksehYqCbjh:22 a=mtcElmGe8wx6H7Xd9tIj:22 a=v10HlyRyNeVhbzM4Lqgd:22 a=gp7W3T1CZUxA4ewt6LkN:22 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> From: Jonathan de Boyne Pollard To: FreeBSD Arch , FreeBSD Hackers Cc: Supervision Message-ID: <28fa2fa1-d086-6fdf-303c-4a527b807542@NTLWorld.COM> Date: Sun, 29 Oct 2017 06:23:39 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 06:23:44 -0000 Warner Losh: > I was completely unaware of SIGWINCH being used like this on Linux. It > didn't pop up in the quick research I did before implementing this. > > But it would have been nice to know this sooner, but I'm OK with later > since it isn't much later. > Some sources of information for you, and for anyone else interested: * The "System event response" section of my system-manager(1). (http://jdebp.eu./Softwares/nosh/guide/system-manager.html or file:///usr/local/share/doc/nosh/system-manager.html if you have the nosh Guide installed) * The SIGNALS section of Miquel van Smoorenburg's init(8). (http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/man/init.8) * The SIGNALS section of Gerrit Pape's runit(8). (http://smarden.org/runit/runit.8.html) * The SIGNALS section of systemd(8). (https://www.freedesktop.org/software/systemd/man/systemd.html) * The doco for signal handling in Joachim Nilsson's finit. (https://github.com/troglobit/finit/blob/master/doc/signals.md) * Felix von Leitner (2004-09). Speeding up the Linux boot process with minit. https://www.fefe.de/minit/minit-linux-kongress2004.pdf. 11th Linux Kongress. p. 14. * https://unix.stackexchange.com/a/191875/5132 * https://unix.stackexchange.com/a/197472/5132 * https://www.mail-archive.com/supervision@list.skarnet.org/msg01344.html From owner-freebsd-hackers@freebsd.org Sun Oct 29 07:14:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AFCBE5BE17 for ; Sun, 29 Oct 2017 07:14:06 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ABA16EE7C for ; Sun, 29 Oct 2017 07:14:04 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TKE21w0050HtmFq01KE2VZ; Sun, 29 Oct 2017 07:14:02 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=2rVjqWD_AAAA:8 a=6I5d2MoRAAAA:8 a=Tlk_011yz0e4TaU44bsA:9 a=QEXdDO2ut3YA:10 a=_tMouvQisEEA:10 a=Ba0ZfmD9N8QA:10 a=82-kyh_VXv8A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=IjZwj45LgO3ly-622nXo:22 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> To: FreeBSD Arch , FreeBSD Hackers From: Jonathan de Boyne Pollard Message-ID: <69a5ac4b-9f71-d016-1dbc-4cc2ceb78fb0@NTLWorld.COM> Date: Sun, 29 Oct 2017 07:14:01 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:14:06 -0000 Warner Losh: > * There is a new compatibility fastpowercycle/powercycle command, > with all of the same options for cruel system administrators. > > Hmmm, I like this. I'll have to add it to FreeBSD. I should have > thought of it in the first place. > (-: If you want further ideas like this, I've proposed adding a -b flag and boot_bare variable to the kernel and loader for a while, now. Old BSD init can just treat it as identical to -s, but my softwares can definitely make good use of it. * http://jdebp.eu./Softwares/nosh/roadmap.html#Ideas * https://freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project From owner-freebsd-hackers@freebsd.org Sun Oct 29 07:26:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AACA8E5C21E for ; Sun, 29 Oct 2017 07:26:22 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E4FDA6F45E for ; Sun, 29 Oct 2017 07:26:21 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TKSJ1w00L0HtmFq01KSJgQ; Sun, 29 Oct 2017 07:26:19 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=zCF0BwDtR6fGmel4gz4A:9 a=QEXdDO2ut3YA:10 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> To: FreeBSD Arch , FreeBSD Hackers From: Jonathan de Boyne Pollard Message-ID: Date: Sun, 29 Oct 2017 07:26:18 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:26:22 -0000 Warner Losh: > * system-manager now treats SIGWINCH differently on non-Linux > operating systems, treading it as a request to invoke a new > powercycle service. > > SIGRTMIN+6, unused in the systemd system, is the Linux equivalent. > > * system-manager now treats SIGRTMIN+16 as the underlying actual > powercycle request, which it translates to either RB_POWERCYCLE if > it is present in the C library headers, or RB_AUTOBOOT if it is not. > > * There is now a new system-control powercycle subcommand, which > defaults to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16. > > It looks like all the SIGRT* signals are user defined, and can be used > for any purpose by the application. It could easily be SIGRTMIN+6 as > it is SIGWINCH and we could ditch SIGWINCH on FreeBSD in init as well > (since it's only been in -current for a few days). Would that suffice > to address the compatibility concerns? There's no reason to be > gratuitously different here. > True, but it's not my softwares that you and I have to worry about. I've just double checked, and the very thing that my softwares themselves are being compatible with here has already used SIGRTMIN+16 and SIGRTMIN+6, so I am going to adjust to +17 and +7 . I'll let the systemd people know. Let's see what transpires from that. From owner-freebsd-hackers@freebsd.org Sun Oct 29 08:34:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D647E5D924 for ; Sun, 29 Oct 2017 08:34:13 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA74716B0 for ; Sun, 29 Oct 2017 08:34:13 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6BFC1E5D923; Sun, 29 Oct 2017 08:34:13 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BA4EE5D922 for ; Sun, 29 Oct 2017 08:34:13 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40441716AF for ; Sun, 29 Oct 2017 08:34:13 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x234.google.com with SMTP id z195so9042682ywz.6 for ; Sun, 29 Oct 2017 01:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=pSAeAxxa1mHTcyFmCQgID/tit/0OBVgTVjlIiry/5DI=; b=oZwldnNQ2cLxDjNY3lzK4QBPrjitg1K9fy0SWPvlZdYKgN9OYS2hxHUjmW4/6rS66w Yo7A5M7ReUTxtbyDCa6N/LZbUzI/YGrhkUlAHXNGxeqHN/5AbU2fb5Y23g6x5VQCc9dj zkarNhdN8nzjGgldqqMlJhjdzMGMbGcIo8nxQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pSAeAxxa1mHTcyFmCQgID/tit/0OBVgTVjlIiry/5DI=; b=bIduompSxm3VflTJ0ZoP435q3AQFkYpL1VPb7kzrL0efeheURpdVUEtNXY6RVdhOoy ZtUGOLeaa8Nughk98+MT6Y3WYmSagewfZet3g8oePdHQ7UKDpEmXUhc1QGsW2XxI3Ldl GK5zQkdbsiDXOxXjga49V4Yn/9rCWEjWJKOfLSHXjSY88m5DxSCSxpkATqb4Q/AD7JX9 jhfRH00Nl/cjv7XkXir1IICdLCTb+FCt2iizU7RcBuiffsjkp+eszNsNqS7gyow3ST7z 4LkPZPTZOIYw6p52Rl0IooArriPpivhydj8mgKf2Oz5OKLYsl68zvik0nkpqa8QmTDs+ XEdg== X-Gm-Message-State: AMCzsaUdQhm+/re7C9czb9IErGpGqfnYEAQ6UkUe84m8LFPZa48J2g6r 7fBWjVdZ1b+0andagDtbxoSE8g3lR0CTlcxAAqSkK/kZ X-Google-Smtp-Source: ABhQp+RDh6QK+h58LWSl+FbKjfy3dRV2LAxSR30eEvjrdoX9CxQF1/7RLZ40h2+cIgWeF0DSu5+xaa1TDG4+AtkhOXU= X-Received: by 10.13.203.196 with SMTP id n187mr3854189ywd.18.1509266051979; Sun, 29 Oct 2017 01:34:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.56.66 with HTTP; Sun, 29 Oct 2017 01:33:41 -0700 (PDT) From: Eitan Adler Date: Sun, 29 Oct 2017 01:33:41 -0700 Message-ID: Subject: removal of share/dict/freebsd To: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 08:34:13 -0000 Hi all, Does anyone object to removing the file share/dict/freebsd ? It has not been functionally updated since 2005, and was last touched at all in 2014. While I could add several more terms of the list, there are better sources of dictionary files available now, and user don't rely on this particular source for anything. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Sun Oct 29 09:11:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9454FE5E561 for ; Sun, 29 Oct 2017 09:11:30 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 707477263D for ; Sun, 29 Oct 2017 09:11:30 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6CB14E5E560; Sun, 29 Oct 2017 09:11:30 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C1CDE5E55F for ; Sun, 29 Oct 2017 09:11:30 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 333867263B for ; Sun, 29 Oct 2017 09:11:30 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id p186so20969901ioe.12 for ; Sun, 29 Oct 2017 02:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wtpysPv3XUzZIpkJpPSSej6eMfwns9KlT5yLMZ+McxA=; b=hy2dihp2E+N7xrvpnPxYReBJS/dCFW+b1ziQ4JLZvRoNiKDFlOMT00dgUte7u3YMle mxDdptRGaLsOH5Q2dM3bBFzYFnZgGrM67ULf3jHLebiLslgwos1o2q+Kh2tRt8fmGdnt QaOpEFUIfnJUavxpPbelXScCqJdtSRNeqWP/z4fJhs4Hxpd6NV5O5gKIkyp/voXNHu0x 88t8pdhURpG3NDEFvSXYohy1EQezOW22eq0IiKfLZlbyLwg5XqQ5zSJtvsNvWug6K4R8 ZOotlj0UXMRcjw2/4mA+pb7D7rITT4nK8TWFcRYwahsderWGUA+EZsn9CYXqumEaza1S a7vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wtpysPv3XUzZIpkJpPSSej6eMfwns9KlT5yLMZ+McxA=; b=OVOa+dFNt2i9Dm04jWvu54lS+QzcqqHPYyA/eXLBZ67jtuAVAAvX73azWlEL5FjQbs KXEdBdEsHPcJFHQqBMeBJsLV2GSceML9rfyf2632/BHoKfYxhPUWxiTRHfaTJozWPwag mlgn9WF1l+zLz5YYqnQMs3CAgBdoJlxYoiLE9mCEWibzvyvPcEtGnE4Uf/XZCNbw1rol tYn9T4sQaD4RnbRVWyd/++qjv9C8ckExdrfFv2iK/xcyhbtzoy73H6w5A45AL5VDRz0M TAm6N9Bv9jq49oU+RT0eDE6GqwIHE3gKaQTWAX5Qkw6TTgKUj25uXbMAZYSB87cXBuz3 THWg== X-Gm-Message-State: AMCzsaVBsUegGZTapqYyzPDmWji/tTTY7cmLJK3ADqVkp6Kv27GVjLln DE4CNbiGkDhUAhMkA0iHppbGVmXxzPWbyWJgBlA= X-Google-Smtp-Source: ABhQp+QNahgJDSHcP7fWOwcNYKe/LvwuvPVps/Tt/DyrkoacfKt6PLjo/thjrdKhkYiTK7Jh/fD8qxlBu7OsZWmI6yc= X-Received: by 10.36.91.76 with SMTP id g73mr1692475itb.3.1509268289348; Sun, 29 Oct 2017 02:11:29 -0700 (PDT) MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 10.107.166.148 with HTTP; Sun, 29 Oct 2017 02:11:28 -0700 (PDT) In-Reply-To: References: From: Antoine Brodin Date: Sun, 29 Oct 2017 10:11:28 +0100 X-Google-Sender-Auth: hTCSov1wfUp4_nnlkWxBG3aF9SA Message-ID: Subject: Re: removal of share/dict/freebsd To: Eitan Adler Cc: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 09:11:30 -0000 On Sun, Oct 29, 2017 at 9:33 AM, Eitan Adler wrote: > Hi all, > > Does anyone object to removing the file share/dict/freebsd ? It has > not been functionally updated since 2005, and was last touched at all > in 2014. > > While I could add several more terms of the list, there are better > sources of dictionary files available now, and user don't rely on this > particular source for anything. Hi, What is the benefit of the removal, aside from breaking look(1) and some regression tests? Cheers, Antoine From owner-freebsd-hackers@freebsd.org Sun Oct 29 07:05:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F03FEE5BA8D; Sun, 29 Oct 2017 07:05:35 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B3B106E993; Sun, 29 Oct 2017 07:05:35 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7F819273A4; Sun, 29 Oct 2017 07:05:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9T75QhH028040; Sun, 29 Oct 2017 07:05:26 GMT (envelope-from phk@phk.freebsd.dk) To: Eric McCorkle cc: Benjamin Kaduk , Ben Laurie , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28038.1509260726.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Oct 2017 07:05:26 +0000 Message-ID: <28039.1509260726@critter.freebsd.dk> X-Mailman-Approved-At: Sun, 29 Oct 2017 10:58:12 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:05:36 -0000 -------- In message , Eric Mc= Corkl e writes: >On 10/28/2017 09:15, Poul-Henning Kamp wrote: >> -------- >> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk wri= tes: >> = >>> I would say that the 1.1.x series is less bad, especially on the last = count, >>> but don't know how much you've looked at the differences in the new br= anch. >> = >> While "less bad" is certainly a laudable goal for OpenSSL, I hope >> FreeBSD has higher ambitions. >> = > >I'm curious about your thoughts on LibreSSL as a possible option. It retains the horrible APIs, so the potential improvement is finite. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Sun Oct 29 11:31:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A993E60F43 for ; Sun, 29 Oct 2017 11:31:06 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3178376448 for ; Sun, 29 Oct 2017 11:31:05 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 7E37E23D1ED for ; Sun, 29 Oct 2017 12:31:03 +0100 (CET) Subject: Re: Crypto overhaul To: freebsd-hackers@freebsd.org References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Matthias Andree Message-ID: Date: Sun, 29 Oct 2017 12:31:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: de-DE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 11:31:06 -0000 Am 29.10.2017 um 02:36 schrieb Eric McCorkle: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: >> -------- >> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >> >>> I would say that the 1.1.x series is less bad, especially on the last count, >>> but don't know how much you've looked at the differences in the new branch. >> While "less bad" is certainly a laudable goal for OpenSSL, I hope >> FreeBSD has higher ambitions. >> > I'm curious about your thoughts on LibreSSL as a possible option. To me as application developer (fetchmail) and user of FreeBSD on a vserver as web/mail server, I've seen LibreSSL break its users too often, require extra hoops to detect its old API as opposed to OpenSSL 1.1.x/1.0.x distinction, so it gambled away the little trust I had and I've cast it out again from my computers and just committed the bare minimals to detect and warn about LibreSSL. Just going on a rampage with the fork, badmouthing OpenSSL (which has come quite a way since LibreSSL forked off), doesn't quite build the case for LibreSSL to become a fully-fledged SSL/TLS/crypto replacement stack for OpenSSL, in my book. From owner-freebsd-hackers@freebsd.org Sun Oct 29 13:46:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4851AE63B4D; Sun, 29 Oct 2017 13:46:35 +0000 (UTC) (envelope-from bf1783@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 058327E4E6; Sun, 29 Oct 2017 13:46:34 +0000 (UTC) (envelope-from bf1783@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id n22so7792673uaj.13; Sun, 29 Oct 2017 06:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=G4UHpup1LKcJW4HHj7KPsqUTIe18RGjnzQxd9Ph3rXU=; b=SudsWfA8VD6TE1AjNJxb8guApfUhtJ0XiCzE/0Kaj3ci6xsMAVk8V8UeOefyw6eFn4 ZaSWGZThOyGowjD/H8FcpraUHOOFQ6WhbqVj8Y+yP/RJahdNQan+wmQKcKu6UUbrIquv llhG+pLvJf4RVqAWMG1m2SAGk0d3THKaZ3i4sVOQZ9kfczICW06CXGOo28R6BCoV9gLN CKDTtxmVDfKKFteJ0WO1+xQ1hEDbDWUmASPsyn+80DIG9URGoOtkgpf4v2LHsmuPKdO0 YEkL093P2EgzVgQMVIqhsUjnSi8pX1AyHTLK/dq21s7T09LclrE69437WnKONRKr05GJ DPIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=G4UHpup1LKcJW4HHj7KPsqUTIe18RGjnzQxd9Ph3rXU=; b=CQ7wBuILzPdK4XsoJfgmv6waMKkavmN2ih64XenNVMmusrNt5aTnnqttCSWFD+7Iu+ aJvsKsASwkw6xFR2/gUsGWmnAMFiNPE2bXXhqdhAFSVEn1JKiK3rR2ev+giVaIoY4h51 VyLd7W2KbZtGBrP/cz2lVVjDVau4FxVxSuyKQHPPFeoN8G2NtKhcL/GULEK4ba2OtBve jjrQfVgTayVwAPiMr4suR/jVk2C+pKuXpm7JdgjBDg0gQ81k/f2xuUk2UOWUpVKOnO9f Zi9BHDg6LU/+mCLcGXOcnZ2k/RhAzsijsLRAIpiPflTDo3Epjzok2CDwcE0g5/nSw8Ta md8g== X-Gm-Message-State: AMCzsaX6GkW+xpxY8Vv1Aw9Rn4Y253qTDDvQko57naasmKJnU8smQtbn YsK/gKfFDB5pbirDCA0hZMKel6nDnkkfxYRASxU= X-Google-Smtp-Source: ABhQp+SqMUXHwYgKpGF6enWQxc3auR2/uOGU+VmWxHOuqNUTDYYP3+nUugIr2yAYeD2Lp8l+pjKzyWTqKdxstSk2yoc= X-Received: by 10.176.83.206 with SMTP id l14mr5789821uaa.167.1509284793938; Sun, 29 Oct 2017 06:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.143.142 with HTTP; Sun, 29 Oct 2017 06:46:33 -0700 (PDT) Reply-To: bf1783@gmail.com In-Reply-To: <28039.1509260726@critter.freebsd.dk> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> From: bf Date: Sun, 29 Oct 2017 13:46:33 +0000 Message-ID: Subject: Re: Crypto overhaul To: Poul-Henning Kamp Cc: Eric McCorkle , Benjamin Kaduk , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 13:46:35 -0000 On 10/29/17, Poul-Henning Kamp wrote: > -------- > In message , Eric > McCorkl > e writes: >>On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>> -------- >>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>> writes: >>> >>>> I would say that the 1.1.x series is less bad, especially on the last >>>> count, >>>> but don't know how much you've looked at the differences in the new >>>> branch. >>> >>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>> FreeBSD has higher ambitions. >>> >> >>I'm curious about your thoughts on LibreSSL as a possible option. > > It retains the horrible APIs, so the potential improvement is finite. > OpenBSD started the task of making OpenSSL easier to use by adding things like libtls (see https://man.openbsd.org/tls_init ) on top of their backwards-compatible libssl. There are similar efforts in other libraries like NaCl and its forks, such as libsodium ( cf. https://nacl.cr.yp.to/features.html and https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these the kind of changes you are suggesting? Regards, b.f. From owner-freebsd-hackers@freebsd.org Sun Oct 29 13:56:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D070E3A0CB for ; Sun, 29 Oct 2017 13:56:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-106.reflexion.net [208.70.210.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FB0E7EC1A for ; Sun, 29 Oct 2017 13:56:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11883 invoked from network); 29 Oct 2017 13:50:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 13:50:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 09:50:10 -0400 (EDT) Received: (qmail 6352 invoked from network); 29 Oct 2017 13:50:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 13:50:09 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 55C86EC7B89; Sun, 29 Oct 2017 06:50:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> Date: Sun, 29 Oct 2017 06:50:08 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 13:56:57 -0000 [Message history removed as this does not flow well with the prior material.] I've figured out the mismatch and, so, why/how lib32 fails for devel/powerpc64-gcc based builds: the .init code generation for devel/powerpc64-gcc is tied to the glibc crti.S for powerpc and that does not match what FreeBSD has for the interface between the two parts. As of 6 years ago or so glibc has code like (I'm only dealing with the init side of things as an example): .section .init,"ax",@progbits stwu r1, -16(r1) . . . bcl 29,31,.LMAGIC_LABEL .LMAGIC_LABEL: mflr r30 addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha addi r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@l . . . (some pre-init function code) . . . that comes before code that is from frame_dummy and __do_global_ctors_aux (that are from /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c = ). The code generated for frame_dummy and __do_global_ctors_aux expects r30 to already be set up for _GLOBAL_OFFSET_TABLE_ related use by the kind of code that I showed above. Instead FreeBSD has for powerpc just: (things are configured for devel/powerpc64-gcc to use it) #include __FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $"); .section .init,"ax",@progbits .align 2 .globl _init .type _init,@function _init: stwu 1,-16(1) mflr 0 stw 31,12(1) stw 0,20(1) mr 31,1 The overall result ends up being (from an example .so): 0000214c <_init> stwu r1,-16(r1) 00002150 <_init+0x4> mflr r0 00002154 <_init+0x8> stw r31,12(r1) 00002158 <_init+0xc> stw r0,20(r1) 0000215c <_init+0x10> mr r31,r1 (The above is the FreeBSD crti.S code.) (Note the lack of initialization of r30 to the _GLOBAL_OFFSET_TABLE_ related value.) (The below is the crtstuff.c frame_dummy code inlined in a way that the function prolog code is not present here.) (Note the dependence on r30 having already been initialized.) 00002160 <_init+0x14> lwz r3,-712(r30) 00002164 <_init+0x18> lwz r9,0(r3) 00002168 <_init+0x1c> cmpwi cr7,r9,0 0000216c <_init+0x20> beq- cr7,00002184 <_init+0x38> 00002170 <_init+0x24> lwz r9,-16(r30) 00002174 <_init+0x28> cmpwi cr7,r9,0 00002178 <_init+0x2c> beq- cr7,00002184 <_init+0x38> 0000217c <_init+0x30> mtctr r9 00002180 <_init+0x34> bctrl (The below is the crtstuff.c __do_global_ctors_aux loop code but inlined. . .) 00002184 <_init+0x38> lwz r29,-36(r30) 00002188 <_init+0x3c> lwzu r9,-4(r29) 0000218c <_init+0x40> cmpwi cr7,r9,-1 00002190 <_init+0x44> beq- cr7,000021a8 <_init+0x5c> 00002194 <_init+0x48> mtctr r9 00002198 <_init+0x4c> bctrl 0000219c <_init+0x50> lwzu r9,-4(r29) 000021a0 <_init+0x54> cmpwi cr7,r9,-1 000021a4 <_init+0x58> bne+ cr7,00002194 <_init+0x48> (The rest of the .init code follows.) 000021a8 <_init+0x5c> lwz r11,0(r1) 000021ac <_init+0x60> lwz r0,4(r11) 000021b0 <_init+0x64> mtlr r0 000021b4 <_init+0x68> lwz r31,-4(r11) 000021b8 <_init+0x6c> mr r1,r11 000021bc <_init+0x70> blr The way the compiler's source code is structured and works it looks to me like the crti.S used needs to have the initialization code for r30. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Oct 29 15:18:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CE3AE40E8F; Sun, 29 Oct 2017 15:18:00 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 00BC6810D6; Sun, 29 Oct 2017 15:17:59 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4A18018C4; Sun, 29 Oct 2017 15:17:59 +0000 (UTC) Subject: Re: Crypto overhaul To: bf1783@gmail.com, Poul-Henning Kamp Cc: Benjamin Kaduk , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> From: Eric McCorkle Message-ID: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> Date: Sun, 29 Oct 2017 11:17:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 15:18:00 -0000 On 10/29/2017 09:46, bf wrote: > On 10/29/17, Poul-Henning Kamp wrote: >> -------- >> In message , Eric >> McCorkl >> e writes: >>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>> -------- >>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>> writes: >>>> >>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>> count, >>>>> but don't know how much you've looked at the differences in the new >>>>> branch. >>>> >>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>> FreeBSD has higher ambitions. >>>> >>> >>> I'm curious about your thoughts on LibreSSL as a possible option. >> >> It retains the horrible APIs, so the potential improvement is finite. >> > > OpenBSD started the task of making OpenSSL easier to use by adding > things like libtls > > (see https://man.openbsd.org/tls_init ) > > on top of their backwards-compatible libssl. There are similar > efforts in other libraries like NaCl and its forks, such as libsodium > ( cf. https://nacl.cr.yp.to/features.html and > https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these > the kind of changes you are suggesting? I know the LibreSSL roadmap includes more plans to improve the API design to make it more usable. Overall, I think LibreSSL is the best option, though there needs to be some investigation into how easily it can be used for kernel and boot-loader purposes. Things like libsodium are too narrow in their focus, and BearSSL is too new. Plus the fact that LibreSSL originates from one of the BSDs and has its backing is a significant advantage, I think. From owner-freebsd-hackers@freebsd.org Sun Oct 29 16:32:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE0C3E46241; Sun, 29 Oct 2017 16:32:55 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0104.outbound.protection.outlook.com [104.47.36.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A65383D50; Sun, 29 Oct 2017 16:32:54 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CzDh1clqxHoUZ9hYUWmhxj3MAg1XOBuapGYdsOQC0po=; b=D7DcmpAN+MNU1spcqjpRQSyWAmfO3/QMfmwcGLMrwkaU6Qlly7gclY4dP3A2sH+5mId7x6JNgaEO+nsVY3tYi1wyCnWbb/XSmfL0Ge+xxsFFioDBSz5Nx9zbrEkQaMvQw77+q5cZgioI7VzkKA0dSZjDqjVdcbHZrOGo0UJciWc= Received: from DM5PR05CA0053.namprd05.prod.outlook.com (10.174.188.170) by MWHPR05MB3613.namprd05.prod.outlook.com (10.174.251.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Sun, 29 Oct 2017 16:32:52 +0000 Received: from DM3NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by DM5PR05CA0053.outlook.office365.com (2603:10b6:4:39::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Sun, 29 Oct 2017 16:32:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT038.mail.protection.outlook.com (10.152.98.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.197.9 via Frontend Transport; Sun, 29 Oct 2017 16:32:51 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 29 Oct 2017 09:32:44 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9TGWh4b021885; Sun, 29 Oct 2017 09:32:43 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 89C53385567; Sun, 29 Oct 2017 09:32:43 -0700 (PDT) To: Eric McCorkle CC: , Poul-Henning Kamp , "freebsd-security@freebsd.org security" , Benjamin Kaduk , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Subject: Re: Crypto overhaul In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> Comments: In-reply-to: Eric McCorkle message dated "Sun, 29 Oct 2017 11:17:58 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95043.1509294763.1@kaos.jnpr.net> Date: Sun, 29 Oct 2017 09:32:43 -0700 Message-ID: <95044.1509294763@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(2980300002)(199003)(24454002)(189002)(69596002)(39060400002)(107886003)(47776003)(2950100002)(305945005)(4326008)(221733001)(6916009)(356003)(6266002)(6246003)(50466002)(9686003)(68736007)(55016002)(7696004)(2906002)(5660300001)(77096006)(7116003)(229853002)(53936002)(97756001)(8676002)(54906003)(8936002)(316002)(46406003)(7126002)(76176999)(23726003)(16586007)(2810700001)(50986999)(105596002)(81156014)(81166006)(53416004)(97876018)(189998001)(106466001)(76506005)(50226002)(478600001)(117636001)(97736004)(3480700004)(86362001)(93886005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3613; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT038; 1:BmGzebx+tizseAkHeIUGxoAM0qcDGcBNsP0dVSHjW5KkdAQKkM2nquWsDn0NXv1tg85I7aG/nKbYrHr55A+Ollsk/Fjxup/v4xxCbPcAQXBPfa7wWWEebH4JoNdVxpcU X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b3a3bb25-7021-4aaa-e928-08d51eeab339 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 3:bLgK3bY0Shy1Q/Hv2FK1t9xbCh/b+ttzpHj+NhFT7Yn02y8ojIngZ13LXCGLvyGOXwj72YwlTE1PvYYj4HX1gO/noz2U87ApukbhsC+0mzh0HDTZWsxPyjGyN4udnddLA0B89avgdGYLQoBTybM+FwMawPYpBkWekjTTPBAbTH42O9LADPyomOe9YXosCKvzd3YeL/HSMUBPLcqrCrM7FAslbUopLfu8te+FTFoBoDrF5BZtxZmW19Snc8yRBls2VI97wM4ZyAbsp4XXL+HPjCBH2hfFl4EWLNfSaf+jZGVSiLl+wOhwTl6KlMxCzVgzW/6eeQ/gNRSyCugEXVVoSxeOxxlvJ6RPPilAOXQ4QD8=; 25:2R5Pb5Jo9W3vsog9iH7gbfWorcUPPbHMjtUsFLtQai6mo9zr7HW5UJ5otTTxTt55HDLwHiDaQA2D3OxHCBMi7hqELIg2/yTGepAI/ra/8BUVYwfc3iZm2maKz8dWMtqGFKhLX/omD69t2J6r+a7nfcnjfT0RpUI69wo+JsUxy/rifdFeqJYa/HUbwf4eyzxFlXhPJzUQsgJUL394iTZ6IM6gF2Hg3ZDWxRqAiwKudHE6djRswtMgC149XApow5Rj60724BhRDdcL37kvCohkFezsKDpTvls8Iv9XsdoHyYZfhv2Cl18WIWJEF2PuMPC7hZHEKnnN2oKNX25gH7Qxyw== X-MS-TrafficTypeDiagnostic: MWHPR05MB3613: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 31:wm2gF+if/HESKjQCwHUx2Je7xDBuMh0CGBmoqQ2oEirHDi1c+48oAdN2tShfdNLQzCrNofqi7e9WLZ9pEsTjcntkYxJYb1z3X3iSuBGeVI68wHZmCFQqFrnbk9JXjGi+MKhz0uYfnZQ/pQLKxhxNL4Qx0mKRUrQVNWyGO73QuwtgP88HsomsNspN++rPSIsJ7U296M7FXKEeGnyGfq7JxPxU2UNAay/62AUGm4xmrmg=; 20:++bdJFmfX7xZp7hW1j2a/Quntk6FENa0En+4r/f65xkl5P2YYYyQgbRG1vrb1e/B9w6wpSV0PLd7ZcIfuJVbTdPLMtF96ED4Ccyke3hOrUi9F9OlD/xYiTmNyDiAfW3hCahrC1mXIo+fb+I1OihycTyr80xo+Ey3FytH+ikLCBOiEAVN+Nhiq29LOfAz2BnM5bNSXFi7aQMugZEMQjx4iOIuMiqjc81SGWDv75AWMuon4MSaTOIk13wTmd+xC08Whf/f9rL61J0Qvt0ml//jj4lBzAodn8HfNnCQheFzMDCXBegQWmosFuhB477iiQ9Q+OIiCUr1IurfqN0V4vNOnfAbYyI+Wqe5DSWdLxSmeV09HBiktMzJAjMjJxrUmZfSgeaSSpG941x8ym4QlcK5pDt1/UN8GAWVPqAPgc/fmpLe29d7KJmnqteVh/sVmqyGZjDTSBU0eOeKki9JJ3xUev/6BMEu0m3ECJL2gRwywR5lh9fm/UpLu3TmPA2og8i9 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93003095)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3613; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 4:uMOiNQsnJluh2Re5B6oAxIZRBuHYj6qENT0fgc1zMLz10rGIOj007CDYXwum8HIj5zA+cytVGDoaTwvjpubDK6hNUlYUMqdrSCUYANBdb3sJOaLOB0xTm7nk4UHTuo5mxyWBOEv14lFL+1CFPtSdnKP5g39pql7x+DFzFdy1CVz1n+MoyOXuU+P6GiUTkYNUmZvqb7CH+zRzcEikExV+x9tRYA3xbjGtNz/IMsUqhGh6oklqRsRf5AzaTFp9dBRGDlnVUiF6vywLpuCd93U/wQ== X-Forefront-PRVS: 0475418F50 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3613; 23:yCpu+/LqPxjKLASkkkfQyloL41PBjBlKaEJjRrpMI?= =?us-ascii?Q?saCXbMo5Ypd1RpmkqhPTT0pPiqryj2J3JKqVUSDj3rZJKeSe4sh/O9BkUTez?= =?us-ascii?Q?Wju196Zf8fv4O5pUR6xt3yAEJZbnIL26eyqPD7a8P+puYH6zypprtIZSxutn?= =?us-ascii?Q?73g7z+xSGi999JIJUxordVQ3SI73jTvkcj5gCceSc79g9/6N4n+pFzZlAsjv?= =?us-ascii?Q?pViIPXLoc7gPDk3GicShVDAI9lpDiIyCvn/ReaHy5UXAdJ7YZ4Py1tMfzeh1?= =?us-ascii?Q?loOCIny69lsCQX7v8Fbcaa0L9mF1T0j3d0h2Ihtq6TkBBSTbxcpfI0pfb7Gz?= =?us-ascii?Q?a6Z446KyWMwRvhjPfsNZesYZCxCvuDOwzXQEB2JBS7/lbzgFMMYtEdfkIiHT?= =?us-ascii?Q?W3yc4r+FyywR53lhhGR66kqB9NSmYxsf+uXpRMPZ3Yj4ciopZnL7NJxSl0n2?= =?us-ascii?Q?MDJokJ6MNsnnftNPqv8jmFeL7+DvQn56lE/mcCI6xWxjFs2Gk0ggdLBbFKOT?= =?us-ascii?Q?0PJrr+0BKI4CqqOrXSAgPR/BvNEETp0DZVcezjYc3ag+rSN25RTFmywqkMzF?= =?us-ascii?Q?vce1pobcc2DA/cMWH57+CM/zMbHpOlhN7bqkbHxQcKfqafBcalJsVUYwZ9Xa?= =?us-ascii?Q?xfm6NVusgybrYjm6uF5tb0f+eig7d+N1ic01L9rWtCOl3YB6s+zqYoTqXIY5?= =?us-ascii?Q?3hr6KNVibdrKkCpZT3lz8OT60Ky+q3nml+R39mxbucTnA2ISkPnOeNtwB4kj?= =?us-ascii?Q?sOpXPnWb44LpVY/ml/MoUV5b1nKbvHNCOZtJPLDNoYWxUM6Yk1UkRMM8sEVJ?= =?us-ascii?Q?tIj1k+0aOenxW9UpUdsmsr5F77NgQXfC7R0uBd6gdLyKMSLu/YG54Fv4dYtE?= =?us-ascii?Q?/S/rEK+HG4OxUIMoa9MefL/6PMA4Vf8BUnkRBIBnsyn4NrzRRBt/0itp0tiX?= =?us-ascii?Q?zr/HXV+RMVbdHe2lo5mLkJZStIGKqY+5WerD7WbVcYIBugWCECvrNmmASLgE?= =?us-ascii?Q?kSXkz/GNov5TngDKO3jnWMcjRQL8H8W3Ypa7Rv5UjslFVrIR/7veR+7C2CUU?= =?us-ascii?Q?Wsjg7FNeJO+x4fu+Ba5je5YfEubeOMsYa8LzTyFMIswabIJMbAR17WP3lPBP?= =?us-ascii?Q?k9PzKW9Ltwf3Z8X7QfNkduJe2dfXhObsT1qV09b/8BVEEZ/TFVzZzCrH8Y5o?= =?us-ascii?Q?kNmQaBtTdz6KYJXraT5qfNmcyQyUvTrHEzcxMn4G8WbGGuH0D/wWGInSc72Z?= =?us-ascii?Q?jFe/G0NFY9UvHGBJ3YGS39S/HdibSBjOq5oyuQFsd750V7D/urA2vUPVnlfY?= =?us-ascii?Q?TE+ob63WvmaCbooBFea2pZ28wBq4A8yYm3N9lNUKgx7?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 6:eEHU3pjfCt7i6ArWSmL8OXvD24uOJ/SNM+ujZmFjuQMrsvs8bTzExu94Kwvu6N9PKKqFI3p2Z27JYYILVdSXPuo5N0oUzjT600w8P4+jU7g1N9hzk9bgeh+Gc9MaJWrfeCMcEFOUv0wCqWHdjAKIskmB53S+OouECtSB4NX67ayIHeWIF1aszffB71HS5RAn/TUbwEbeMguSNyfz/jA7T9sY17NCS4djW+4BbmKCn7G9tAW3FOV5vC9XTy10gFZMepUwFifNxuYTI7k1Vr0/azYT2XKjp2GemOk4eRQFMTNxHE7fyXJExw7Gpf12rbXdlhPt/f10kDCmaGX8va/8dVW1ZLMWyq0eqo/neDwGZY4=; 5:dLz/hTJ/rTR4iF3Fnsbdw1SkYWIGaxp4sotHPbniD7pFTig9iMqbdk79DEPxtd5E69Y8J98yB/AuTXfy7/IgklRdtKvX853M+YPgfATzo04HQu6XGSTqN6CQM++ZfxfSOjuP9DpxE1wPnkeeSqE/C8qXkD1ycBuZOtFjaDqqMPA=; 24:gcjPSsI4fkdMikhRUzntLi3d5mmfyvfM2esZafz0KaQGSU8WYdi+nd0QSnbgXZfVQZlH0XqpgfTxbV2/zBZLRZ8BzCYd9AhfMj7NwRr/vz0=; 7:oaLcwtnT9773JR4cUa39WOVAC6CVfZJONndCmL9Sz6NTeYQToJrAf7FJb6hX7b/hbSzl+PfzwrNMxieCiEUVysByLL9HWZObHiFrJbnRl5YcWH55q4DCVR4ZSBfa+LQlNR+uNxtNWdR3AutImcANAXKs32IxJrHL6/1AtrmVUA4XQGfnYGXdzlbwjv87eIL6joXpbcLtDCN94mlU/5sVlryFEw/d8as3LC2p1qr1Desxw9MG3K/P66hDWypbCLDm SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2017 16:32:51.5103 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b3a3bb25-7021-4aaa-e928-08d51eeab339 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3613 X-Mailman-Approved-At: Sun, 29 Oct 2017 17:03:17 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:32:55 -0000 Eric McCorkle wrote: > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. Our userland veriexec binary uses a libverify which is mostly just OpenSSL (originally structured that way for export reasons ;-) is 3.6M - at least 90% of that is just OpenSSL. I tried paring that library down to just the bits needed for loader. But had to give up at 3M. Which was when I encounterd BearSSL. Out of the box, it could verify our ECDSA cert chains as well as various RSA ones which was a pleasant surprise. libbearssl is < 1M and my loader is 347K with verifcation vs 237K without, so the entire verifcation implementation is only 110K --sjg From owner-freebsd-hackers@freebsd.org Sun Oct 29 17:15:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0CCBE475D7; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9465D3D4; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id x82so13545215qkb.12; Sun, 29 Oct 2017 10:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=bjSZ1Y5IhkazDMzTcfW2GEKDpV9cpLSj73QkxfldZqtTNn6kyVO6B8JVtaBRWM+N9U 7Wq02fQsjosLL7Jv9fX2ONrakCnz/1IB2nJOKyLjgIbn/zovHvMSs5yVqKrla/IJ7SL4 lxQqIL29Ay+Xn9EI/ERl0Ram6ZpPByr6Jz2UBeGKrXqdyZsavjsuynW1nQp6uFolIU7Q QEHZydTVU9K24bZMmE5NyUMn5Sg3y072y3LXX5HP5qQ5jRsuHaKf6PrtySfL6dHexY/d KJJJQTfoRot9mLAvqu3vZoFxFQiO99Y2OmNrw8U1zujWhZGGOL4uA/0O+tONJ+sbr1r4 u84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=ktaoKyARD/rwJdWMtd8IdWIgveryEkf/iXs7jAkYCVv7Rf8mR0uf3nr8iJEuw263dO 8DMnXRxFz0UfbyVYrt0EjTR+aF5x1cTJJ3fcbEHNQQSw3RspPwS9YZwsQLdg5Rlcl7Dn GzQLOW/rNBw+dFiygTyffCJ7/UlzsSu22hzNxPS0QCEOuQcef6Wcmgg/BfI8rXe4jDOa uY1RHWKLJ7Y/Ua1cKlzcFf3RRyC3tqPZleRqeAQxVnEAO2ah/zG9eMWhKc4uXlN1OXCR aYmIxd257HCtG5Vdb2eOTIjyapQPK5xB76h998k3g0KHKT+gs63YhqofRHEwXkyA1i1H U21A== X-Gm-Message-State: AMCzsaWaSG83MkoKTbep5LstQ16Y/xfjDSUJtVfCflHTqqFhsuPS/hWI dZw8fXhePgrDK8uknLJQqJemDcB1iCz1qNSbJUs= X-Google-Smtp-Source: ABhQp+SHLAgMCXgjFKe2WMS89jNcGetcVG7fne3MoLNveq0lAcg97BCgjl7cLYIPXQbZ377mzsJi5JCKQmyA7tvKe/k= X-Received: by 10.55.197.20 with SMTP id p20mr9680636qki.229.1509297314773; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> From: Ben Laurie Date: Sun, 29 Oct 2017 17:15:14 +0000 X-Google-Sender-Auth: YL3p4S4Fawfv-h3A9jWw9YR424Y Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: bf1783@gmail.com, Poul-Henning Kamp , Benjamin Kaduk , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:15:16 -0000 On 29 October 2017 at 15:17, Eric McCorkle wrote: > On 10/29/2017 09:46, bf wrote: >> On 10/29/17, Poul-Henning Kamp wrote: >>> -------- >>> In message , Eric >>> McCorkl >>> e writes: >>>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>>> -------- >>>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>>> writes: >>>>> >>>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>>> count, >>>>>> but don't know how much you've looked at the differences in the new >>>>>> branch. >>>>> >>>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>>> FreeBSD has higher ambitions. >>>>> >>>> >>>> I'm curious about your thoughts on LibreSSL as a possible option. >>> >>> It retains the horrible APIs, so the potential improvement is finite. >>> >> >> OpenBSD started the task of making OpenSSL easier to use by adding >> things like libtls >> >> (see https://man.openbsd.org/tls_init ) >> >> on top of their backwards-compatible libssl. There are similar >> efforts in other libraries like NaCl and its forks, such as libsodium >> ( cf. https://nacl.cr.yp.to/features.html and >> https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these >> the kind of changes you are suggesting? > > I know the LibreSSL roadmap includes more plans to improve the API > design to make it more usable. > > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. > > Plus the fact that LibreSSL originates from one of the BSDs and has its > backing is a significant advantage, I think. Mostly it originates from OpenSSL. :-) From owner-freebsd-hackers@freebsd.org Sun Oct 29 19:13:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35D10E4A150; Sun, 29 Oct 2017 19:13:19 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62F6E635CB; Sun, 29 Oct 2017 19:13:17 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-135ff7000000649f-9a-59f6271477b6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 99.E9.25759.41726F95; Sun, 29 Oct 2017 15:08:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9TJ82R1009557; Sun, 29 Oct 2017 15:08:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9TJ7wQN022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Oct 2017 15:08:01 -0400 Date: Sun, 29 Oct 2017 14:07:58 -0500 From: Benjamin Kaduk To: Eric McCorkle Cc: Poul-Henning Kamp , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171029190758.GE26855@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSuq/i3SYOFfFotFszktvk0HMmZP n8ZksX3zP0aLnk1P2Cw+fON3YPOY8Wk+i8fmpjlsHvd2TGDy+LR/MlsASxSXTUpqTmZZapG+ XQJXxrZV71kK2tgqfrz+y97A+JKli5GTQ0LAROLo66OMXYxcHEICi5kkpnz9yQrhbGSUeNNx jhnCucok0Xj6EVCGg4NFQFXi0rFUkG42ATWJx3ubwcIiAhoS83cLgpQzCyxjkrjy9QwjSI2w gIzEwbOXmEBsXqBtJ/fsg5p5nVniVM8VqISgxMmZT8BOYhbQkrjx7yUTyFBmAWmJ5f84QMKc As4S686cZwOxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtL LdI118vNLNFLTSndxAgKb3YXlR2M3T3ehxgFOBiVeHgFNL5GCrEmlhVX5h5ilORgUhLl3Xf+ U6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4vct8ihXhTEiurUovyYVLSHCxK4rzbgnZFCgmk J5akZqemFqQWwWRlODiUJHi11IAaBYtS01Mr0jJzShDSTBycIMN5gIYHgtTwFhck5hZnpkPk TzEac9x4eP0PE8ezma8bmIVY8vLzUqXEeTtBSgVASjNK8+CmgVKURPb+mleM4kDPCfMqglTx ANMb3LxXQKuYgFZpSH4BWVWSiJCSamBcpZXbovTy1ttNh0v+G16/2yvz5tLy2/YHd840VcgV +N39cUZh2eucqx8O9zTsC2DRfD/d4eN2H+2jghLvAvXEbq/ecfZxxDEB0elXjU8fYJK9KvX8 KpuRbdFkhqu8tXfU0zTnz3+gsv4ad5HuS4UTt/JfrV3Wy54d7NKVy17EfrrAbVNyn4usEktx RqKhFnNRcSIAXZPVuiwDAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 19:13:19 -0000 On Sat, Oct 28, 2017 at 08:36:01PM -0400, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: > > -------- > > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > > >> I would say that the 1.1.x series is less bad, especially on the last count, > >> but don't know how much you've looked at the differences in the new branch. > > > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > > FreeBSD has higher ambitions. > > > > I'm curious about your thoughts on LibreSSL as a possible option. I haven't been following LibreSSL enough to have an informed opinion, but my uninformed opinion was that OpenSSL proper has been proceeding with modernization at a faster pace than LibreSSL. -Ben From owner-freebsd-hackers@freebsd.org Sun Oct 29 23:13:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5DABE4ED56 for ; Sun, 29 Oct 2017 23:13:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-130.reflexion.net [208.70.210.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9716AC21 for ; Sun, 29 Oct 2017 23:13:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1734 invoked from network); 29 Oct 2017 22:46:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 22:46:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 18:46:48 -0400 (EDT) Received: (qmail 20373 invoked from network); 29 Oct 2017 22:46:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 22:46:48 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D1102EC8683; Sun, 29 Oct 2017 15:46:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> Date: Sun, 29 Oct 2017 15:46:47 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 23:13:35 -0000 [I add notes about what I see in the SysVR4 powerpc ABI document about r30 vs. _GLOBAL_OFFSET_TABLE_ use --and some notes about more modern Power Architecture=C2=AE 32-bit Application Binary Interface Supplement 1.0 material that does, by contrast, specify a type of context where r30 must be used for the purpose. Bugzilla 206123 now has this material as well.] On 2017-Oct-29, at 6:50 AM, Mark Millard wrote: > [Message history removed as this does not flow well with > the prior material.] >=20 > I've figured out the mismatch and, so, why/how lib32 > fails for devel/powerpc64-gcc based builds: the > .init code generation for devel/powerpc64-gcc is tied > to the glibc crti.S for powerpc and that does not > match what FreeBSD has for the interface between > the two parts. >=20 > As of 6 years ago or so glibc has code like (I'm > only dealing with the init side of things as an > example): >=20 > .section .init,"ax",@progbits > stwu r1, -16(r1) > . . . > bcl 29,31,.LMAGIC_LABEL > .LMAGIC_LABEL: > mflr r30 > addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha > addi r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@l > . . . (some pre-init function code) . . . >=20 > that comes before code that is from frame_dummy > and __do_global_ctors_aux (that are from > = /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c = ). >=20 > The code generated for frame_dummy and > __do_global_ctors_aux expects r30 to already > be set up for _GLOBAL_OFFSET_TABLE_ related > use by the kind of code that I showed above. >=20 >=20 > Instead FreeBSD has for powerpc just: > (things are configured for devel/powerpc64-gcc > to use it) >=20 > #include > __FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $"); >=20 > .section .init,"ax",@progbits > .align 2 > .globl _init > .type _init,@function > _init: > stwu 1,-16(1) > mflr 0 > stw 31,12(1) > stw 0,20(1) > mr 31,1 >=20 > The overall result ends up being (from > an example .so): >=20 > 0000214c <_init> stwu r1,-16(r1) > 00002150 <_init+0x4> mflr r0 > 00002154 <_init+0x8> stw r31,12(r1) > 00002158 <_init+0xc> stw r0,20(r1) > 0000215c <_init+0x10> mr r31,r1 > (The above is the FreeBSD crti.S code.) > (Note the lack of initialization of r30 > to the _GLOBAL_OFFSET_TABLE_ related value.) >=20 > (The below is the crtstuff.c frame_dummy code > inlined in a way that the function prolog code > is not present here.) > (Note the dependence on r30 having already been > initialized.) > 00002160 <_init+0x14> lwz r3,-712(r30) > 00002164 <_init+0x18> lwz r9,0(r3) > 00002168 <_init+0x1c> cmpwi cr7,r9,0 > 0000216c <_init+0x20> beq- cr7,00002184 <_init+0x38> > 00002170 <_init+0x24> lwz r9,-16(r30) > 00002174 <_init+0x28> cmpwi cr7,r9,0 > 00002178 <_init+0x2c> beq- cr7,00002184 <_init+0x38> > 0000217c <_init+0x30> mtctr r9 > 00002180 <_init+0x34> bctrl >=20 > (The below is the crtstuff.c __do_global_ctors_aux > loop code but inlined. . .) > 00002184 <_init+0x38> lwz r29,-36(r30) > 00002188 <_init+0x3c> lwzu r9,-4(r29) > 0000218c <_init+0x40> cmpwi cr7,r9,-1 > 00002190 <_init+0x44> beq- cr7,000021a8 <_init+0x5c> > 00002194 <_init+0x48> mtctr r9 > 00002198 <_init+0x4c> bctrl > 0000219c <_init+0x50> lwzu r9,-4(r29) > 000021a0 <_init+0x54> cmpwi cr7,r9,-1 > 000021a4 <_init+0x58> bne+ cr7,00002194 <_init+0x48> >=20 > (The rest of the .init code follows.) > 000021a8 <_init+0x5c> lwz r11,0(r1) > 000021ac <_init+0x60> lwz r0,4(r11) > 000021b0 <_init+0x64> mtlr r0 > 000021b4 <_init+0x68> lwz r31,-4(r11) > 000021b8 <_init+0x6c> mr r1,r11 > 000021bc <_init+0x70> blr >=20 > The way the compiler's source code is structured > and works it looks to me like the crti.S used needs > to have the initialization code for r30. I've looked an a copy of the 1995 Sun Microsystems PPC SYSVR4 ABI document and its table 3-3 about processor register usage is not explicit about a specific register being used relative to _GLOBAL_OFFSET_TABLE_ handling. There are examples that say things like: Assumes GOT pointer in r31 but as far as I can tell no place requires that. In fact there is wording like: Combining the offset with the global offset table address in a general = register (for example, r31 loaded in the sample prologue in Figure 3-33) = gives the absolute address of the table entry holding the desired = address. which explicitly indicates "in a general register". It appears that crti.S type code for share libraries requires a local convention for the choice of register that the compiler and library must agree on. So r30 looks to be a valid choice but possibly compiler specific for a FreeBSD context. But there may be a reason to stick with r30. . . Looking in Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf reports that: Under the Secure-PLT ABI, when using the Position-Independent Code (PIC) = addressing model, register r30 is used (by convention between compiler & = link editor) in nonleaf functions to hold the Global Offset Table (GOT) = pointer. . . . Using r30 to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol is the = current convention used by the compiler and link-editor and is only required for nonleaf = routines which use the PIC addressing model. Leaf routines or code not = using the PIC addressing model may use any available unreserved = general-purpose register to hold the address of the = _GLOBAL_OFFSET_TABLE_ symbol. . . . The PIC call stub sequence requires that the compiler ensure that the = register used to hold the _GLOBAL_OFFSET_TABLE_ pointer is set before = any calls are made from the PLT. The current convention between the = compiler and link editor is that r30 be used for this purpose. This is a = change from the BSS-PLT ABI which only required GOT addressing to access = static storage. . . . For non-PIC code, r30 will not hold the GOT pointer; so the stubs must = be different, as shown in the following implementation. . . . Note: This ABI does not require a fixed GOT register, or even one = register used throughout a binary. Non-PIC code does not set the = _GLOBAL_OFFSET_TABLE_ pointer and does not need to reserve a register = for that purpose. Code under the PIC addressing model that accesses = static storage or calls nonlocal functions will need a register to hold = the _GLOBAL_OFFSET_TABLE_ pointer. However, leaf functions or functions = that only call other functions which are static (@local) may use any = general-purpose register within the constraints for the existing ABI. [End quotes.] By contrast Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf does not say much about r30 use, including not specifying the Secure-PLT ABI material. The referenced documents are examples of: Power Architecture=C2=AE 32-bit Application Binary Interface Supplement = 1.0 documents published in, for example, 2011 (Power.org copyright for that date but various other copyrights for various earlier dates). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Mon Oct 30 02:45:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5ACB8E52578 for ; Mon, 30 Oct 2017 02:45:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-161.reflexion.net [208.70.210.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B88C7029C for ; Mon, 30 Oct 2017 02:45:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22466 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Oct 2017 02:38:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 22:38:56 -0400 (EDT) Received: (qmail 1149 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Oct 2017 02:38:56 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 68E15EC9443; Sun, 29 Oct 2017 19:38:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> Date: Sun, 29 Oct 2017 19:38:54 -0700 Cc: freebsd-hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 02:45:44 -0000 I've found a way in which crti.o and crtbeginS.o and the like are broken for cross builds such as amd64 -> powerpc64 based builds: These first --print-file-name outputs are from on my amd64 -> powerpc64 cross build environment: # which clang /usr/bin/clang # clang --print-file-name=3Dcrti.o /usr/lib/crti.o # clang -m32 --print-file-name=3Dcrti.o /usr/lib32/crti.o # clang --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # clang -m32 --print-file-name=3DcrtbeginS.o /usr/lib32/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o crti.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o crti.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o = = crtbeginS.o (Note the lack of path prefixes above: they are not explicitly from /usr/local/lib/. . . for some reason. System ones would not be appropriate. Note that nothing differentiates -m32 use.) It looks like the path oddities cause lack of dining any crti.o or crtbeginS.o or the like, which causes the compiler/linker to work differently from different materials that are internal to devel/powerpc64-gcc . # gcc7 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 -m32 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 --print-file-name=3DcrtbeginS.o /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o # gcc7 -m32 --print-file-name=3DcrtbeginS.o = = = /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o (Odd mix of system and gcc7 materials above? Note the lack of -m32 having a distinct path as well.) On my (clang built) powerpc64 environment powerpc64-unknown-freebsd12.0-gcc ends up with different results: # clang --print-file-name=3Dcrti.o /usr/lib/crti.o # clang -m32 --print-file-name=3Dcrti.o /usr/lib32/crti.o # clang --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # clang -m32 --print-file-name=3DcrtbeginS.o /usr/lib32/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o /usr/lib/crti.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o /usr/lib/../lib32/crti.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o /usr/lib/../lib32/crtbeginS.o (Path prefixes present above. Using system ones would not be likely to match using /usr/local/lib/. . . ones from a cross build environment. But to have builds from both hosts be equivalent would require the hosts to use the same files [by content].) # gcc7 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 -m32 --print-file-name=3Dcrti.o /usr/lib/../lib32/crti.o # gcc7 --print-file-name=3DcrtbeginS.o /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o # gcc7 -m32 --print-file-name=3DcrtbeginS.o = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/32/crtbeginS.o= (Again the odd(?) system vs. gcc mix for gcc7. But the -m32 path is distinct in this context.) Does devel/powerpc64-gcc for cross builds require taking control of the crti.o and crtbeginS.o (and . . .) generation to force a match to what self-hosted would have on the target architecture? (nothing found.) Note that /usr/local/. . . does not even have the likes of crti.o or crtbeginS.o (or so on) for devel/powerpc64-gcc to use in cross builds: # find /usr/local/ -name "crtbeginS.o" -print | more = = =20 /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o (This also confirms that lack of a . . ./32/crtbeginS.o for the amd64 native gcc7 compiler.) It appears that devel/powerpc64-gcc used for cross builds is generating what would otherwise be crti.o and crtbeginS.o content on the fly as needed during its compiles: there are none around to use the contents of. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Mon Oct 30 04:36:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B3BEE53D6E for ; Mon, 30 Oct 2017 04:36:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 64032732AD for ; Mon, 30 Oct 2017 04:36:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6038FE53D6D; Mon, 30 Oct 2017 04:36:02 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DF99E53D6C for ; Mon, 30 Oct 2017 04:36:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B75D732AB for ; Mon, 30 Oct 2017 04:36:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22b.google.com with SMTP id w5so10434530ywg.11 for ; Sun, 29 Oct 2017 21:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IA8C218AHX3Ih3yF+i6702fYfQ43BBx51d3cEJUhjvI=; b=noRKIIGg+3p8ucMr3u+DYFbmcp6S8ZNO3D0PLW5taPWNqvMKp2LzyS7pHPs12tN+Xb KJ2EoYkgXLBQz2M1AFOWtqpnXBBd5GvSSxuTj4ZZHszi98tPlYXyheMkovjwQ8h6lNJL ATCODzLZ+yNyjRiUK+ysWsy3Eo5bP/OB6lOr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IA8C218AHX3Ih3yF+i6702fYfQ43BBx51d3cEJUhjvI=; b=bX5DtL6FrZWBlnhYBP7DpqfoyDizv0GRG9I41hFKAZd0OrpSDPAjhFc/GEei4b6MX2 kowrdzMSK+dA5Co4O8rjW8UpS7MxATl5rCPsabR9NqO/bHLUdeaGIRm6j4ypxvnIm4BJ CH4SQ9XdFyqNQyvDSmQuu+RA+yhHQZp1zOdX2YbZpTcapuT+4N7MD3Bmfk6M34S4X/E8 ydlaFg8U/c1FhDvP7utWppZ4EVRdr3F/PN+SxEdXCPu33uq2I2U7jnI+t8917NduAMKy gKNOZ9jYqSQSSSNDJzvRgvSu1tFVTGei4BZDCoKYkzIQed9cqQCkPX3jRwwUI2dx/1z5 KsVQ== X-Gm-Message-State: AMCzsaXrvXE6YWwr5dg5R8F1Ik+ox32TlShyB4qDnIkoXw5xGOkL3h6P okRe6L34Nzgz5jjjkPbAaBfUGLNk1a3SqfZkvfYoIQ== X-Google-Smtp-Source: ABhQp+QFXLXEZGIv2nsp+nJw1LBBwfPrUYdkquCTp+rEaIVsbXaiClR6vrHOltynIX4sIwvZKSFdC1vF7jSmtLJzHG8= X-Received: by 10.129.119.66 with SMTP id s63mr5595250ywc.71.1509338161146; Sun, 29 Oct 2017 21:36:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.56.66 with HTTP; Sun, 29 Oct 2017 21:35:30 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 29 Oct 2017 21:35:30 -0700 Message-ID: Subject: Re: removal of share/dict/freebsd To: Antoine Brodin Cc: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 04:36:02 -0000 On 29 October 2017 at 02:11, Antoine Brodin wrote: > On Sun, Oct 29, 2017 at 9:33 AM, Eitan Adler wrote: >> Hi all, >> >> Does anyone object to removing the file share/dict/freebsd ? It has >> not been functionally updated since 2005, and was last touched at all >> in 2014. >> >> While I could add several more terms of the list, there are better >> sources of dictionary files available now, and user don't rely on this >> particular source for anything. > > Hi, > > What is the benefit of the removal, aside from breaking look(1) and > some regression tests? Not having old mostly-useless stuff laying around. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Mon Oct 30 07:24:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAF54E5627B for ; Mon, 30 Oct 2017 07:24:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-104.reflexion.net [208.70.210.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F42E77741 for ; Mon, 30 Oct 2017 07:24:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22218 invoked from network); 30 Oct 2017 07:23:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Oct 2017 07:23:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 30 Oct 2017 03:23:57 -0400 (EDT) Received: (qmail 29873 invoked from network); 30 Oct 2017 07:23:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Oct 2017 07:23:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D09CAEC8683; Mon, 30 Oct 2017 00:23:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> Date: Mon, 30 Oct 2017 00:23:56 -0700 Cc: freebsd-hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:24:04 -0000 [It is not as bad as I was thinking as far as the --print-file-name output goes.] On 2017-Oct-29, at 7:38 PM, Mark Millard wrote: > I've found a way in which crti.o and crtbeginS.o and > the like are broken for cross builds such as > amd64 -> powerpc64 based builds: >=20 >=20 > These first --print-file-name > outputs are from on my > amd64 -> powerpc64 cross build > environment: >=20 > # which clang > /usr/bin/clang >=20 > # clang --print-file-name=3Dcrti.o > /usr/lib/crti.o > # clang -m32 --print-file-name=3Dcrti.o > /usr/lib32/crti.o >=20 > # clang --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # clang -m32 --print-file-name=3DcrtbeginS.o > /usr/lib32/crtbeginS.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o > crti.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o > crti.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o > crtbeginS.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o= = crtbeginS.o >=20 > (Note the lack of path prefixes above: they are not > explicitly from /usr/local/lib/. . . for some reason. > System ones would not be appropriate. Note that nothing > differentiates -m32 use.) >=20 > It looks like the path oddities cause lack of dining > any crti.o or crtbeginS.o or the like, which causes > the compiler/linker to work differently from > different materials that are internal to > devel/powerpc64-gcc . >=20 > # gcc7 --print-file-name=3Dcrti.o > /usr/lib/crti.o > # gcc7 -m32 --print-file-name=3Dcrti.o > /usr/lib/crti.o >=20 > # gcc7 --print-file-name=3DcrtbeginS.o > /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o > # gcc7 -m32 --print-file-name=3DcrtbeginS.o = = = /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o >=20 > (Odd mix of system and gcc7 materials above? > Note the lack of -m32 having a distinct path > as well.) >=20 > On my (clang built) powerpc64 environment > powerpc64-unknown-freebsd12.0-gcc ends > up with different results: >=20 > # clang --print-file-name=3Dcrti.o > /usr/lib/crti.o > # clang -m32 --print-file-name=3Dcrti.o > /usr/lib32/crti.o >=20 > # clang --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # clang -m32 --print-file-name=3DcrtbeginS.o > /usr/lib32/crtbeginS.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o > /usr/lib/crti.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o > /usr/lib/../lib32/crti.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o= > /usr/lib/../lib32/crtbeginS.o >=20 >=20 > (Path prefixes present above. Using system ones would > not be likely to match using /usr/local/lib/. . . ones > from a cross build environment. But to have builds > from both hosts be equivalent would require the hosts > to use the same files [by content].) >=20 > # gcc7 --print-file-name=3Dcrti.o > /usr/lib/crti.o > # gcc7 -m32 --print-file-name=3Dcrti.o > /usr/lib/../lib32/crti.o >=20 > # gcc7 --print-file-name=3DcrtbeginS.o > = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o > # gcc7 -m32 --print-file-name=3DcrtbeginS.o > = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/32/crtbeginS.o= >=20 >=20 > (Again the odd(?) system vs. gcc mix for gcc7. > But the -m32 path is distinct in this context.) >=20 > Does devel/powerpc64-gcc for cross builds require > taking control of the crti.o and crtbeginS.o (and > . . .) generation to force a match to what > self-hosted would have on the target architecture? > (nothing found.) >=20 >=20 >=20 > Note that /usr/local/. . . does not even have > the likes of crti.o or crtbeginS.o (or so on) > for devel/powerpc64-gcc to use in cross builds: >=20 > # find /usr/local/ -name "crtbeginS.o" -print | more = = =20 > /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o >=20 > (This also confirms that lack of a . . ./32/crtbeginS.o > for the amd64 native gcc7 compiler.) >=20 > It appears that devel/powerpc64-gcc used for cross > builds is generating what would otherwise be > crti.o and crtbeginS.o content on the fly as needed > during its compiles: there are none around to > use the contents of. FYI: despite the lack of a path prefix from --print-file-name . . . It appears to me that what appears in the lib32 .so.* files for .init is from: = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crt*.o content. Apparently without the path prefix it is looking based on other path specifications to find something. It just can not report later what it actually found and used for the file requested. So, not as bad as I was thinking earlier. But these files show the r30 problem and the inlining. You may want to skip the following detail. # find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name = "*crt[in]*.*" -print | more . . . /usr/src/lib/csu/powerpc64/crti.S /usr/src/lib/csu/powerpc64/crtn.S . . . = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crtn.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crti.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crtn.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crti.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtn.o # find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name = "*crt[be]*S.*" -print | more = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtendS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtbeginS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtendS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtbeginS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtbeginS.o Showing -m32 examples: -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3D3 -g0 -DCRT_BEGIN -DCRTSTUFFS_O -DSHARED -fpic -c -o crtbeginS.o /usr/src/contrib/gcc/crtstuff.c -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3D3 -g0 -DCRT_END -DCRTSTUFFS_O -DSHARED -fpic -o crtendS.o /usr/src/contrib/gcc/crtstuff.c =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Mon Oct 30 10:11:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97FEAE593FC for ; Mon, 30 Oct 2017 10:11:56 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [84.52.114.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45FBB8122B; Mon, 30 Oct 2017 10:11:55 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 3F8007F4CE; Mon, 30 Oct 2017 13:11:46 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.9.2 shelob.oktetlabs.ru 3F8007F4CE Authentication-Results: shelob.oktetlabs.ru/3F8007F4CE; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral Subject: Re: Anyone using Solarflare on FreeBSD 10-STABLE ? To: Mark Saad Cc: Philip Paeps , Allan Jude , "freebsd-hackers@freebsd.org" References: <333473BB-43C3-4E3E-B62F-03DE5650E403@freebsd.org> <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> <0d126774-3736-4a4c-c01f-07bc9caf82a6@freebsd.org> From: Andrew Rybchenko Message-ID: Date: Mon, 30 Oct 2017 13:11:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 10:11:56 -0000 On 10/27/2017 09:02 PM, Mark Saad wrote: > On Fri, Oct 27, 2017 at 2:55 AM, Andrew Rybchenko wrote: >> On 10/25/2017 12:04 AM, Mark Saad wrote: >> >> On Tue, Oct 17, 2017 at 3:44 PM, Andrew Rybchenko >> wrote: >> >> Basically the counter means that ingress packet does not match any installed >> filter. E.g. promiscuous mode is disabled and: >> - destination MAC is unicast and not the interface MAC address, OR >> - destination MAC is multicast and there is no matching multicast address >> added. >> >> There is a race condition as well on interface bring up when packet is >> received but default filters are not installed yet. >> >> SFN8522 and SFN8542 have other cases for encapsulated traffic depending on >> driver version (right now I don't remember the state in 10-STABLE). >> >> Mark, let me know if I can help more. >> >> Andrew. >> >> Could you clarify what was meant by Virtual Functions ? Vlans , laggs >> etc or srv-io ? >> Also I do have IGMP snoop enabled and routing is done locally on each >> router -, the freebsd box with the sfxge cards. >> >> >> I meant SR-IOV. Which SF NIC do you use? >> >> Andrew. > Andrew > I am using IIRC 7140's This is what I get from the various utils > > Solarflare Flareon Ultra 7000 Series 10G Adapter > Firmware version: v6.4.3 > Controller type: Solarflare SFC9140 > Boot ROM version: v5.0.4.1000 Do I understand correctly that rxdp_di_dropped_pktsgrows when interface is running? I.e. it is not just few packets at start up. If it is possible, I'd try to enable promisc mode and check if stops the counter grow. If so and traffic is not huge, I'd try to sniff on the interface and filter out traffic to local MAC, broadcast and locally added multicast addresses to check if unexpected traffic comes to the interface. Andrew. From owner-freebsd-hackers@freebsd.org Mon Oct 30 08:06:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25381E56F0D; Mon, 30 Oct 2017 08:06:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8B317CBC4; Mon, 30 Oct 2017 08:06:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (124-148-77-206.dyn.iinet.net.au [124.148.77.206]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9U85v2c088182 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Oct 2017 01:06:03 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: Crypto overhaul To: Eric McCorkle , Poul-Henning Kamp , Benjamin Kaduk Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Julian Elischer Message-ID: Date: Mon, 30 Oct 2017 16:05:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailman-Approved-At: Mon, 30 Oct 2017 10:35:42 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:06:13 -0000 On 29/10/17 8:36 am, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: >> -------- >> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >> >>> I would say that the 1.1.x series is less bad, especially on the last count, >>> but don't know how much you've looked at the differences in the new branch. >> While "less bad" is certainly a laudable goal for OpenSSL, I hope >> FreeBSD has higher ambitions. >> > I'm curious about your thoughts on LibreSSL as a possible option. what gives any evidence as to it being any better? > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 12:47:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7D8BE5C532 for ; Mon, 30 Oct 2017 12:47:34 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD1B16A2 for ; Mon, 30 Oct 2017 12:47:34 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt0-x22a.google.com with SMTP id k31so16126381qta.6 for ; Mon, 30 Oct 2017 05:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rmqfIX1OJp9BU4AcBJYtl/CJBieuAU4RCzMq6IwZT2M=; b=e8gbnSM5OoxhFy7myDGW+dNrRbfscB+EXDZ2pufYwFEptK7P51QH/yiVdDkJVOY/cM hcF28yKtej/qNPrvQna8jWkE5Rl4KJpk56qnsCBSo6fSvvmvLOu67NwGWDfvyUNyXl56 cnrsQpXtO/31mCvsLYlTt9rqD37kQsz2g0/ayEnkTNMAw+wxeKLNgT7M5P3J6rSyx4LA Hz9TVaD6+hWUT4nXNtxYHPAA4uvcuyJQbWwuKjzA0wY73UNVACaPzzCLSN9mCGw4Oax5 j/D0hPts6dOUtSliBJMa9hUIpzyJ4wxfpq81L447hfWzrbJ6iHVNv6uyE+InZ7V5MoVt Wvag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rmqfIX1OJp9BU4AcBJYtl/CJBieuAU4RCzMq6IwZT2M=; b=LKhpKfkJILYrLhT+nCLMDLpI6ae89/VSfMktvAvP7oWWepTd90EUBxQhqc2iqua1U1 n6LKJhM/b1RLZtG1vzOMFQHX3vlxzhapUulybWqbT/clqakx2GFJMZeLqqRv7C34D2GF If56ynLY6UImzUH/kO9QAr+P8AhXNeatY2+pHFxWKlD3MXI1ZSvpAD/NIpNO9t46JwL6 AyW359DJjQLCMlCLgBQ70uXbZuyng/r6z9MZ9czzCspNoTVG5ETctY20z/og0PlJPnaI d45PdtImytB+UFIsKmcNESGtHsdvqTQxKRK0z9TVqAHgteZXsNmBETO+/7qxK5b7J0C9 0TeQ== X-Gm-Message-State: AMCzsaVz6u6/RMl7mw4v49Qs99PnwxrgEMXQaM7tCIJoMRk5AEkh6f+0 Hthi+w7DCQsecXGl1/bD1DNDJeYuhuI= X-Google-Smtp-Source: ABhQp+RSDFn3ggJiLoHdpk78TIIpHLJsAGk0RcK5oLT8Q5z/uDTuFQqnoJDlYFOIfpadXqPvwPF8Bg== X-Received: by 10.200.15.83 with SMTP id l19mr13677990qtk.168.1509367653404; Mon, 30 Oct 2017 05:47:33 -0700 (PDT) Received: from [25.226.247.76] (ool-3f8fc5bb.dyn.optonline.net. [63.143.197.187]) by smtp.gmail.com with ESMTPSA id o71sm9244784qka.74.2017.10.30.05.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 05:47:31 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: Anyone using Solarflare on FreeBSD 10-STABLE ? From: Mark Saad X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Mon, 30 Oct 2017 08:46:51 -0400 Cc: Philip Paeps , Allan Jude , "freebsd-hackers@freebsd.org" Message-Id: <539BFBD6-0F30-46D0-BB23-4C4547542B51@longcount.org> References: <333473BB-43C3-4E3E-B62F-03DE5650E403@freebsd.org> <7951e7d5-b5e6-033d-0b51-1d4a10946937@oktetlabs.ru> <0d126774-3736-4a4c-c01f-07bc9caf82a6@freebsd.org> To: Andrew Rybchenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:47:35 -0000 > On Oct 30, 2017, at 6:11 AM, Andrew Rybchenko wrote= : >=20 >> On 10/27/2017 09:02 PM, Mark Saad wrote: >>> On Fri, Oct 27, 2017 at 2:55 AM, Andrew Rybchenko = wrote: >>> On 10/25/2017 12:04 AM, Mark Saad wrote: >>>=20 >>> On Tue, Oct 17, 2017 at 3:44 PM, Andrew Rybchenko = >>> wrote: >>>=20 >>> Basically the counter means that ingress packet does not match any insta= lled >>> filter. E.g. promiscuous mode is disabled and: >>> - destination MAC is unicast and not the interface MAC address, OR >>> - destination MAC is multicast and there is no matching multicast addre= ss >>> added. >>>=20 >>> There is a race condition as well on interface bring up when packet is >>> received but default filters are not installed yet. >>>=20 >>> SFN8522 and SFN8542 have other cases for encapsulated traffic depending o= n >>> driver version (right now I don't remember the state in 10-STABLE). >>>=20 >>> Mark, let me know if I can help more. >>>=20 >>> Andrew. >>>=20 >>> Could you clarify what was meant by Virtual Functions ? Vlans , laggs >>> etc or srv-io ? >>> Also I do have IGMP snoop enabled and routing is done locally on each >>> router -, the freebsd box with the sfxge cards. >>>=20 >>>=20 >>> I meant SR-IOV. Which SF NIC do you use? >>>=20 >>> Andrew. >> Andrew >> I am using IIRC 7140's This is what I get from the various utils >>=20 >> Solarflare Flareon Ultra 7000 Series 10G Adapter >> Firmware version: v6.4.3 >> Controller type: Solarflare SFC9140 >> Boot ROM version: v5.0.4.1000 >=20 > Do I understand correctly that rxdp_di_dropped_pkts grows when interface i= s running? > I.e. it is not just few packets at start up. Correct the counter is a 6 -7 digit number, depending on which server I am l= ooking at. It increases but I am not exactly sure why of the rate . >=20 > If it is possible, I'd try to enable promisc mode and check if stops the c= ounter grow. > If so and traffic is not huge, I'd try to sniff on the interface and filte= r out traffic to local > MAC, broadcast and locally added multicast addresses to check if unexpecte= d traffic > comes to the interface. >=20 > Andrew. I will try this on my lab and see what happens . Thanks again for the ideas .= --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-hackers@freebsd.org Mon Oct 30 14:27:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7936E5E401 for ; Mon, 30 Oct 2017 14:27:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79B39643C6 for ; Mon, 30 Oct 2017 14:27:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-77-206.dyn.iinet.net.au [124.148.77.206]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9UERL1A090389 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Oct 2017 07:27:24 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Crypto overhaul To: "Wall, Stephen" , "freebsd-hackers@freebsd.org" References: <51e5e3f85b6445ed85faf770773118bb@exch-02.redcom.com> From: Julian Elischer Message-ID: <719ce87c-88de-2d54-bac1-c9020c845993@freebsd.org> Date: Mon, 30 Oct 2017 22:27:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <51e5e3f85b6445ed85faf770773118bb@exch-02.redcom.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:27:27 -0000 On 27/10/17 8:38 pm, Wall, Stephen wrote: > Be aware that moving away from a crypto library that has a FIPS-approved crypto core will have a significant impact on commercial users of FreeBSD who do business with U.S. government (and likely some other governments and corporate sectors as well). BoringSSL is persuing/has persued FIPS validation, but they offer this warning on their web page: This is a HUGE issue for $JOB as our government customers require this. Not having it would result in a rip-out of our product from their sites, or us being stranded on the last version supporting openssl. The alternative is to make sure everything including the base system is compiled against the openSSL port, or more precisely the FiPS variant.. (how would one even do that?) > > > Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability. > > > > BearSSL, being a new, small project, is highly unlikely to pursue FIPS certification. LibreSSL has deliberately stripped anything FIPS related out of their fork, and the project has stated multiple times that it will not come back. > > > > I am not opposing a change (indeed, consolidating the various crypto sources in FreeBSD to single (FIPS-possible) library would be a good thing) , I just prefer (strongly) that FIPS not be pushed out of the picture. > > > > -spw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Oct 30 21:20:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E03CE65B38; Mon, 30 Oct 2017 21:20:50 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 208CA72178; Mon, 30 Oct 2017 21:20:50 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id B475B465026; Mon, 30 Oct 2017 16:14:31 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2001:1900:2254:206a::19:2; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mx0.esc7.net (Postfix) with ESMTPS id BDB77461B05 for ; Sat, 28 Oct 2017 19:36:23 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 6D8FE79260; Sun, 29 Oct 2017 00:36:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 33A0E247D; Sun, 29 Oct 2017 00:36:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D1CE52640; Sun, 29 Oct 2017 00:36:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id EE25822B0; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6CDA0176E; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) Subject: Re: Crypto overhaul To: Poul-Henning Kamp , Benjamin Kaduk References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 20:36:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <24228.1509196559@critter.freebsd.dk> Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: B475B465026.A2FE4 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:20:50 -0000 On 10/28/2017 09:15, Poul-Henning Kamp wrote: > -------- > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > >> I would say that the 1.1.x series is less bad, especially on the last count, >> but don't know how much you've looked at the differences in the new branch. > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > FreeBSD has higher ambitions. > I'm curious about your thoughts on LibreSSL as a possible option. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 21:11:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 959CAE65895; Mon, 30 Oct 2017 21:11:37 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BCD571B31; Mon, 30 Oct 2017 21:11:37 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id B96E946353D; Mon, 30 Oct 2017 16:05:21 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 4A309461C37 for ; Sat, 28 Oct 2017 03:03:58 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id A56638C837; Sat, 28 Oct 2017 08:03:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 76A48672E8; Sat, 28 Oct 2017 08:03:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAC5EE5E67A; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7977D6723E; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9503027374; Sat, 28 Oct 2017 08:03:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9S83Wap023377; Sat, 28 Oct 2017 08:03:34 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk Subject: Re: Crypto overhaul In-reply-to: <20171028022557.GE96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> MIME-Version: 1.0 Content-ID: <23375.1509177812.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 08:03:32 +0000 Message-ID: <23376.1509177812@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: B96E946353D.A475F X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=5.001, required 3, autolearn=disabled, FOREIGN_DOMAIN 3.00, HEADER_FROM_DIFFERENT_DOMAINS 0.00, NEW_TLDS 3.50, NEW_TLDS_1 3.50, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-Mailman-Approved-At: Mon, 30 Oct 2017 21:33:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:11:37 -0000 -------- In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: >But I think the main issue with OpenSSL in base that was leading to >thoughts about replacing it is the mismatch between FreeBSD release >branch support lifecycles and OpenSSL release branch support lifecycles. That's not why I want OpenSSL gone from the tree. My reason is that I think OpenSSLs architecture, (to the extent you can talk about OpenSSL having one), APIs and the source code are all horrible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 21:34:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 931AAE6611B; Mon, 30 Oct 2017 21:34:21 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (rmx0.esc7.net [72.53.186.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4983172CF2; Mon, 30 Oct 2017 21:34:20 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 8DBFA465E05; Mon, 30 Oct 2017 16:27:55 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 3F0F2461B8E for ; Sun, 29 Oct 2017 18:39:30 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 1D805806F3; Sun, 29 Oct 2017 23:39:27 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CAB866B31C; Sun, 29 Oct 2017 23:39:26 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35D10E4A150; Sun, 29 Oct 2017 19:13:19 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62F6E635CB; Sun, 29 Oct 2017 19:13:17 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-135ff7000000649f-9a-59f6271477b6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 99.E9.25759.41726F95; Sun, 29 Oct 2017 15:08:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9TJ82R1009557; Sun, 29 Oct 2017 15:08:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9TJ7wQN022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Oct 2017 15:08:01 -0400 Date: Sun, 29 Oct 2017 14:07:58 -0500 From: Benjamin Kaduk To: Eric McCorkle Subject: Re: Crypto overhaul Message-ID: <20171029190758.GE26855@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSuq/i3SYOFfFotFszktvk0HMmZP n8ZksX3zP0aLnk1P2Cw+fON3YPOY8Wk+i8fmpjlsHvd2TGDy+LR/MlsASxSXTUpqTmZZapG+ XQJXxrZV71kK2tgqfrz+y97A+JKli5GTQ0LAROLo66OMXYxcHEICi5kkpnz9yQrhbGSUeNNx jhnCucok0Xj6EVCGg4NFQFXi0rFUkG42ATWJx3ubwcIiAhoS83cLgpQzCyxjkrjy9QwjSI2w gIzEwbOXmEBsXqBtJ/fsg5p5nVniVM8VqISgxMmZT8BOYhbQkrjx7yUTyFBmAWmJ5f84QMKc As4S686cZwOxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtL LdI118vNLNFLTSndxAgKb3YXlR2M3T3ehxgFOBiVeHgFNL5GCrEmlhVX5h5ilORgUhLl3Xf+ U6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4vct8ihXhTEiurUovyYVLSHCxK4rzbgnZFCgmk J5akZqemFqQWwWRlODiUJHi11IAaBYtS01Mr0jJzShDSTBycIMN5gIYHgtTwFhck5hZnpkPk TzEac9x4eP0PE8ezma8bmIVY8vLzUqXEeTtBSgVASjNK8+CmgVKURPb+mleM4kDPCfMqglTx ANMb3LxXQKuYgFZpSH4BWVWSiJCSamBcpZXbovTy1ttNh0v+G16/2yvz5tLy2/YHd840VcgV +N39cUZh2eucqx8O9zTsC2DRfD/d4eN2H+2jghLvAvXEbq/ecfZxxDEB0elXjU8fYJK9KvX8 KpuRbdFkhqu8tXfU0zTnz3+gsv4ad5HuS4UTt/JfrV3Wy54d7NKVy17EfrrAbVNyn4usEktx RqKhFnNRcSIAXZPVuiwDAAA= X-Mailman-Approved-At: Sun, 29 Oct 2017 23:39:24 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: "freebsd-security@freebsd.org security" , Poul-Henning Kamp , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 8DBFA465E05.A6C5C X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-1.499, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, NEW_TLDS 3.50, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:34:21 -0000 On Sat, Oct 28, 2017 at 08:36:01PM -0400, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: > > -------- > > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > > >> I would say that the 1.1.x series is less bad, especially on the last count, > >> but don't know how much you've looked at the differences in the new branch. > > > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > > FreeBSD has higher ambitions. > > > > I'm curious about your thoughts on LibreSSL as a possible option. I haven't been following LibreSSL enough to have an informed opinion, but my uninformed opinion was that OpenSSL proper has been proceeding with modernization at a faster pace than LibreSSL. -Ben _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 21:55:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13A51E66AB4; Mon, 30 Oct 2017 21:55:01 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3A2B73C12; Mon, 30 Oct 2017 21:55:00 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 44553462C6E; Mon, 30 Oct 2017 15:42:44 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id ADA82461B84 for ; Thu, 26 Oct 2017 19:29:22 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 3977166CBB; Fri, 27 Oct 2017 00:29:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6FD6F959; Fri, 27 Oct 2017 00:29:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4B41E56CEF; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 918E86F945; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7E7A912D3; Fri, 27 Oct 2017 00:29:08 +0000 (UTC) To: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Crypto overhaul Message-ID: Date: Thu, 26 Oct 2017 20:29:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 44553462C6E.A38B7 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:55:01 -0000 I was going to wait a bit to discuss this, but it's very pertinent to the trust infrastructure I described earlier this week. There was a good bit of discussion at vBSDCon about a possible crypto overhaul. This is my understanding of the current situation: * Userland crypto support is provided by OpenSSL, of course. My sense is that there's a general dissatisfaction with OpenSSL, but that there's a nontrivial effort required to liberate userland from it. * The kernel has sort of two crypto APIs: crypto and opencrypto. The design of these APIs seems to be something of older hardware crypto architectures and export restrictions. This is difficult to extract from the kernel (and say, embed into the boot loader). * BIOS geli pulled the AES implementation out of opencrypto. This was due in a large part to the size restrictions on BIOS loaders. * As a bridge measure, I've introduced boot_crypto into the EFI loader, in order to support GELI. At vBSDcon, there seemed to be a consensus that this situation is too fragmented. Moreover, it makes life difficult for anyone (like me) who wants to do crypto-related projects. A couple of options were discussed at vBSDcon. The two that seemed to come to the forefront were BearSSL and LibreSSL. There seem to be some advantages and disadvantages both ways: * LibreSSL is mature software with staff and support from another BSD (OpenBSD), they've done some really good work, and have a definite long-term roadmap. I'm not sure to what extent it could be easily embedded into a kernel and bootloader, though. * BearSSL's design seemingly lends itself to acting as a userland, kernel, and bootloader library. On the other hand, it's new (which means it will need to be reviewed by crypto experts and thoroughly tested), and has one developer at this point. I think it's worth discussing and investigating these options further at this point. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 23:15:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6E2E264A1; Mon, 30 Oct 2017 23:15:10 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E6AD762C0; Mon, 30 Oct 2017 23:15:10 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id E90D9464F54; Mon, 30 Oct 2017 16:13:56 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2001:1900:2254:206a::19:2; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mx0.esc7.net (Postfix) with ESMTPS id B3689461B84 for ; Sat, 28 Oct 2017 18:31:27 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id C727D6A5A4; Sat, 28 Oct 2017 23:31:18 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3E983FAD; Sat, 28 Oct 2017 23:31:18 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FE22E50747; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3B66D83D9B; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9489D174B; Sat, 28 Oct 2017 23:31:06 +0000 (UTC) Subject: Re: Crypto overhaul To: John Hein , freebsd-arch@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@FreeBSD.org References: <4207-1509111977-98568@sneakemail.com> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 19:31:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4207-1509111977-98568@sneakemail.com> Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: E90D9464F54.A3255 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:15:10 -0000 On 10/27/2017 09:46, John Hein wrote: > What's the overhaul goal here? There's basic crypto libraries with > symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, > openssl's libcrypto). There's libraries that add support for SSL/TLS > & X.509 certificates and such. There's stuff to support using > crypto hardware (accelerators, secure crypto token storage devices). > > And is the thought to [eventually] replace openssl in base with > something lighter perhaps? > > I assume we're looking for bsd, isc, mit, etc., style licenses only. > Sorry for being slow to reply. There's a couple of goals that seem to be in common here (and which I've seen reflected in the comments to my original posting. * Dissatisfaction with the OpenSSL codebase and its history of vulnerabilities. * Desire to consolidate the crypto implementations, specifically, for a crypto library that can serve userland, kernel, and bootloaders. * In my case, the trust framework stuff I wrote about requires public-key crypto in the kernel and loader, which isn't something the kernel crypto framework can do. * It's also harder to add new ciphers when there's multiple crypto codebases. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Oct 30 23:48:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34626E26EAF; Mon, 30 Oct 2017 23:48:20 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (rmx0.esc7.net [72.53.186.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD08A77281; Mon, 30 Oct 2017 23:48:19 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 192E24652AF; Mon, 30 Oct 2017 16:25:18 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 0F387461C0D for ; Sun, 29 Oct 2017 13:31:58 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 635B081296; Sun, 29 Oct 2017 18:31:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 22F4A3237; Sun, 29 Oct 2017 18:31:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0CCBE475D7; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9465D3D4; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id x82so13545215qkb.12; Sun, 29 Oct 2017 10:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=bjSZ1Y5IhkazDMzTcfW2GEKDpV9cpLSj73QkxfldZqtTNn6kyVO6B8JVtaBRWM+N9U 7Wq02fQsjosLL7Jv9fX2ONrakCnz/1IB2nJOKyLjgIbn/zovHvMSs5yVqKrla/IJ7SL4 lxQqIL29Ay+Xn9EI/ERl0Ram6ZpPByr6Jz2UBeGKrXqdyZsavjsuynW1nQp6uFolIU7Q QEHZydTVU9K24bZMmE5NyUMn5Sg3y072y3LXX5HP5qQ5jRsuHaKf6PrtySfL6dHexY/d KJJJQTfoRot9mLAvqu3vZoFxFQiO99Y2OmNrw8U1zujWhZGGOL4uA/0O+tONJ+sbr1r4 u84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=ktaoKyARD/rwJdWMtd8IdWIgveryEkf/iXs7jAkYCVv7Rf8mR0uf3nr8iJEuw263dO 8DMnXRxFz0UfbyVYrt0EjTR+aF5x1cTJJ3fcbEHNQQSw3RspPwS9YZwsQLdg5Rlcl7Dn GzQLOW/rNBw+dFiygTyffCJ7/UlzsSu22hzNxPS0QCEOuQcef6Wcmgg/BfI8rXe4jDOa uY1RHWKLJ7Y/Ua1cKlzcFf3RRyC3tqPZleRqeAQxVnEAO2ah/zG9eMWhKc4uXlN1OXCR aYmIxd257HCtG5Vdb2eOTIjyapQPK5xB76h998k3g0KHKT+gs63YhqofRHEwXkyA1i1H U21A== X-Gm-Message-State: AMCzsaWaSG83MkoKTbep5LstQ16Y/xfjDSUJtVfCflHTqqFhsuPS/hWI dZw8fXhePgrDK8uknLJQqJemDcB1iCz1qNSbJUs= X-Google-Smtp-Source: ABhQp+SHLAgMCXgjFKe2WMS89jNcGetcVG7fne3MoLNveq0lAcg97BCgjl7cLYIPXQbZ377mzsJi5JCKQmyA7tvKe/k= X-Received: by 10.55.197.20 with SMTP id p20mr9680636qki.229.1509297314773; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.22.174 with HTTP; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> From: Ben Laurie Date: Sun, 29 Oct 2017 17:15:14 +0000 X-Google-Sender-Auth: YL3p4S4Fawfv-h3A9jWw9YR424Y Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle X-Mailman-Approved-At: Sun, 29 Oct 2017 18:31:47 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: Benjamin Kaduk , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , bf1783@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 192E24652AF.A5B23 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.889, required 3, autolearn=disabled, DKIM_SIGNED 0.10, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00, T_DKIM_INVALID 0.01) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:48:20 -0000 On 29 October 2017 at 15:17, Eric McCorkle wrote: > On 10/29/2017 09:46, bf wrote: >> On 10/29/17, Poul-Henning Kamp wrote: >>> -------- >>> In message , Eric >>> McCorkl >>> e writes: >>>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>>> -------- >>>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>>> writes: >>>>> >>>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>>> count, >>>>>> but don't know how much you've looked at the differences in the new >>>>>> branch. >>>>> >>>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>>> FreeBSD has higher ambitions. >>>>> >>>> >>>> I'm curious about your thoughts on LibreSSL as a possible option. >>> >>> It retains the horrible APIs, so the potential improvement is finite. >>> >> >> OpenBSD started the task of making OpenSSL easier to use by adding >> things like libtls >> >> (see https://man.openbsd.org/tls_init ) >> >> on top of their backwards-compatible libssl. There are similar >> efforts in other libraries like NaCl and its forks, such as libsodium >> ( cf. https://nacl.cr.yp.to/features.html and >> https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these >> the kind of changes you are suggesting? > > I know the LibreSSL roadmap includes more plans to improve the API > design to make it more usable. > > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. > > Plus the fact that LibreSSL originates from one of the BSDs and has its > backing is a significant advantage, I think. Mostly it originates from OpenSSL. :-) _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Oct 31 11:48:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A517CE56992; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 792AB71232; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 123DA1DDD; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) Subject: Re: Crypto overhaul To: Julian Elischer , Poul-Henning Kamp , Benjamin Kaduk Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Tue, 31 Oct 2017 07:48:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 11:48:41 -0000 On 10/30/2017 04:05, Julian Elischer wrote: > On 29/10/17 8:36 am, Eric McCorkle wrote: >> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>> -------- >>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>> writes: >>> >>>> I would say that the 1.1.x series is less bad, especially on the >>>> last count, >>>> but don't know how much you've looked at the differences in the new >>>> branch. >>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>> FreeBSD has higher ambitions. >>> >> I'm curious about your thoughts on LibreSSL as a possible option. > > what gives any evidence as to it being any better? At least as about its first year and a half, LibreSSL had a markedly better track record than OpenSSL (zero high-severity CVEs vs 5 from OpenSSL, about half as many mid- and low-security CVEs). From owner-freebsd-hackers@freebsd.org Tue Oct 31 12:09:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15F16E5800F; Tue, 31 Oct 2017 12:09:45 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD0DC72793; Tue, 31 Oct 2017 12:09:44 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id o187so20084086qke.7; Tue, 31 Oct 2017 05:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wpRNTOTDupguLPkaIn3o1twQ9MjBa86KKEqmRsmt7js=; b=cKcPV2Asr7MwWu9I+hxbTE1NOr7BGHsM/n+mIykg+K4xW12obc9mwkuS3R9YCXHmo7 DXfiKTWgteC1a1a3hVXLznmUW4HZtK4mQWyf5TAGFgag8ks/EEd+aczFAdv3tgMZ9lG3 xTH+Pm7XvBH8uRAHAcW/yTilB3Hx4pt17TTUa1OWYgOE3Rulr5+SelM0izpbjS41mxEO 71+MhjPcBy/xpwIYDsZkoe4iwrJS7VwELB8dCC84dPCCB471qiatkijyjawV5YjLo7M6 VPBRbzhOb/wEqX2ww5FvFB+OTtgI7TSVy14mXgUV75dBS9MY8axTHqeQXaqUXUeuMo3w I5xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wpRNTOTDupguLPkaIn3o1twQ9MjBa86KKEqmRsmt7js=; b=gYaIFxRu3fYMiaNyeGFboOgI8HAas6XN1tF8VmYCeecamwT/h94WH+JEjvvlrwhD0f NpvPfrIFhissZW9fHDD1sgys7XZOYcwoenP2C7OKimyaMG6HWdlIKSRfI9p3LUSq5b6E pSbO/SklqIlODKFw5Zpmcsu4x5GzK2VfaZMq9HHOCNBpkK/Xqho6AD4DcP4T9nIakQzQ Iug+vNEkPBrO/NyEJpIXcFb0SG9zuBPmt/lDNodAKbniTeq0pvFeHVadDsCMPIc0ByuH kvX9k3UhIC8PXUm1Kh6lxTt04wWbP7Y6WM64bdWrYEeZzQt5pk7bVfjAWxWg0mSjQKG7 PW/A== X-Gm-Message-State: AMCzsaXct582tlfHKXWHAkm3b6RBgqwOdilGh1wDX7JKGK+AVKlF1zbK ljQCnf2wj2uZN/R1gWrRKTo2h6R9JO/cr4uNbJB08yGD X-Google-Smtp-Source: ABhQp+S/TDvaQXKiQvwlsgaEFRMjMkBunKHz2I5lieLwYWeDPn0UOyoyqZnA9EYCZc+7/pl6ik0NrAK22N/gfYyEuyo= X-Received: by 10.55.39.145 with SMTP id n139mr2379578qkn.70.1509451783826; Tue, 31 Oct 2017 05:09:43 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Tue, 31 Oct 2017 05:09:43 -0700 (PDT) In-Reply-To: References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Ben Laurie Date: Tue, 31 Oct 2017 12:09:43 +0000 X-Google-Sender-Auth: OojgfRKA5KJ3YvZD77rXtAuGFCc Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: Julian Elischer , Poul-Henning Kamp , Benjamin Kaduk , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 12:09:45 -0000 On 31 October 2017 at 11:48, Eric McCorkle wrote: > On 10/30/2017 04:05, Julian Elischer wrote: >> On 29/10/17 8:36 am, Eric McCorkle wrote: >>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>> -------- >>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>> writes: >>>> >>>>> I would say that the 1.1.x series is less bad, especially on the >>>>> last count, >>>>> but don't know how much you've looked at the differences in the new >>>>> branch. >>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>> FreeBSD has higher ambitions. >>>> >>> I'm curious about your thoughts on LibreSSL as a possible option. >> >> what gives any evidence as to it being any better? > > At least as about its first year and a half, LibreSSL had a markedly > better track record than OpenSSL (zero high-severity CVEs vs 5 from > OpenSSL, about half as many mid- and low-security CVEs). Not getting CVEs doesn't mean not having the issues: https://marc.info/?l=openbsd-announce&m=140752800525709. From owner-freebsd-hackers@freebsd.org Tue Oct 31 12:24:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BB3BE58809; Tue, 31 Oct 2017 12:24:34 +0000 (UTC) (envelope-from swall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB6C734D3; Tue, 31 Oct 2017 12:24:33 +0000 (UTC) (envelope-from swall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id E42CCA043; Tue, 31 Oct 2017 08:24:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmeTgvPpBMCa; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 4B5DFA02A; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from exch-02.redcom.com (exch-02.redcom.com [192.168.32.9]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id v9VCO0l29495; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) by exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Oct 2017 08:24:00 -0400 Received: from exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b]) by exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b%12]) with mapi id 15.00.1178.000; Tue, 31 Oct 2017 08:24:00 -0400 From: "Wall, Stephen" To: "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: RE: Crypto overhaul Thread-Topic: Crypto overhaul Thread-Index: AQHTT1k1W13dziFDt0aDYDljK8GQJKL4ZliAgABmMICAAF5RAIAASuEAgAAMbICAAL3/gIACEAMAgAHQlwD//8TWEA== Date: Tue, 31 Oct 2017 12:23:59 +0000 Message-ID: References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.84.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 12:24:34 -0000 > At least as about its first year and a half, LibreSSL had a markedly > better track record than OpenSSL (zero high-severity CVEs vs 5 from > OpenSSL, about half as many mid- and low-security CVEs). Are any of these relevant to the crypto module? Or are they all only appli= cable to the SSL protocol? As I understand the discussion so far, the goal is to unify all the dispara= te crypto pieces in the base system. That could certainly be done using Op= enSSLs libcrypto, and let users select their SSL provider from the ports tr= ee. -spw From owner-freebsd-hackers@freebsd.org Tue Oct 31 23:34:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0B0E4434C; Tue, 31 Oct 2017 23:34:27 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0638B6927C; Tue, 31 Oct 2017 23:34:26 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 772BB1FBA; Tue, 31 Oct 2017 23:34:26 +0000 (UTC) Subject: Re: Crypto overhaul To: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: <1adbe576-2610-573b-f555-3b1a537f25e0@metricspace.net> Date: Tue, 31 Oct 2017 19:34:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 23:34:28 -0000 On 10/31/2017 08:23, Wall, Stephen wrote: >> At least as about its first year and a half, LibreSSL had a markedly >> better track record than OpenSSL (zero high-severity CVEs vs 5 from >> OpenSSL, about half as many mid- and low-security CVEs). > > Are any of these relevant to the crypto module? Or are they all only applicable to the SSL protocol? > > As I understand the discussion so far, the goal is to unify all the disparate crypto pieces in the base system. That could certainly be done using OpenSSLs libcrypto, and let users select their SSL provider from the ports tree. That's already how things work, but it doesn't provide a viable solution for kernel and boot loader APIs. There's apparently been at least one attempt to embed OpenSSL into the kernel, to no avail. From owner-freebsd-hackers@freebsd.org Wed Nov 1 00:15:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED7E3E474FB for ; Wed, 1 Nov 2017 00:15:03 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70E626A4AC for ; Wed, 1 Nov 2017 00:15:03 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 61AE5101C; Wed, 1 Nov 2017 01:09:47 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id BmbTzRWhzTpd; Wed, 1 Nov 2017 01:09:42 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 70055FE0; Wed, 1 Nov 2017 01:09:42 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 1C7ED508A1; Wed, 1 Nov 2017 01:09:42 +0100 (CET) Message-ID: <59F910C5.8020709@incore.de> Date: Wed, 01 Nov 2017 01:09:41 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-hackers@freebsd.org Subject: Re: double fault on 10.3-Stable i386 during installworld References: <59D11664.1060206@incore.de> <20171001180943.GO95911@kib.kiev.ua> In-Reply-To: <20171001180943.GO95911@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 01 Nov 2017 00:16:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 00:15:04 -0000 Hello hackers, I still try to find the reason for the "double fault" described in my previous post and can give some more information: On CPU3 runs the thread with tid 100099: (kgdb) tid 100099 Switching to thread 85 (Thread 100099)]#0 0xc0bb6825 in cpustop_handler () at /usr/src/sys/i386/i386/mp_machdep.c:1506 1506 savectx(&stoppcbs[cpu]); (kgdb) f 4 #4 0xc0bb6177 in smp_tlb_shootdown (vector=, addr1=) at /usr/src/sys/i386/i386/mp_machdep.c:1242 1242 while (smp_tlb_wait < ncpu) (kgdb) list 1237 mtx_lock_spin(&smp_ipi_mtx); 1238 smp_tlb_addr1 = addr1; 1239 smp_tlb_addr2 = addr2; 1240 atomic_store_rel_int(&smp_tlb_wait, 0); 1241 ipi_all_but_self(vector); 1242 while (smp_tlb_wait < ncpu) 1243 ia32_pause(); 1244 mtx_unlock_spin(&smp_ipi_mtx); 1245 } 1246 (kgdb) p smp_tlb_wait $1 = 2 (kgdb) p mp_ncpus $2 = 4 (kgdb) p smp_ipi_mtx $3 = {lock_object = {lo_name = 0xc0cc4ba0 "smp rendezvous", lo_flags = 196608, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3372713664} (kgdb) p/x smp_ipi_mtx $4 = {lock_object = {lo_name = 0xc0cc4ba0, lo_flags = 0x30000, lo_data = 0x0, lo_witness = 0x0}, mtx_lock = 0xc90786c0} (kgdb) f 5 #5 0xc0bb6214 in smp_invlpg (addr=) at /usr/src/sys/i386/i386/mp_machdep.c:1311 1311 smp_tlb_shootdown(IPI_INVLPG, addr, 0); (kgdb) list 1306 void 1307 smp_invlpg(vm_offset_t addr) 1308 { 1309 1310 if (smp_started) { 1311 smp_tlb_shootdown(IPI_INVLPG, addr, 0); 1312 #ifdef COUNT_XINVLTLB_HITS 1313 ipi_page++; 1314 #endif 1315 So tid 100099 holds the "smp rendezvous" spin lock, has send the ipi message IPI_INVLPG to the other CPU's and waits for answer of the last CPU. On CPU0 runs the thread with tid 100014: (kgdb) tid 100014 [Switching to thread 37 (Thread 100014)]#0 0xc0bb6825 in cpustop_handler () at /usr/src/sys/i386/i386/mp_machdep.c:1506 1506 savectx(&stoppcbs[cpu]); (kgdb) f 5 #5 0xc0bb613d in smp_tlb_shootdown (vector=246, addr1=3891986432) at /usr/src/sys/i386/i386/mp_machdep.c:1237 1237 mtx_lock_spin(&smp_ipi_mtx); (kgdb) list 1232 ncpu = mp_ncpus - 1; /* does not shootdown self */ 1233 if (ncpu < 1) 1234 return; /* no other cpus */ 1235 if (!(read_eflags() & PSL_I)) 1236 panic("%s: interrupts disabled", __func__); 1237 mtx_lock_spin(&smp_ipi_mtx); 1238 smp_tlb_addr1 = addr1; 1239 smp_tlb_addr2 = addr2; 1240 atomic_store_rel_int(&smp_tlb_wait, 0); 1241 ipi_all_but_self(vector); (kgdb) f 6 #6 0xc0bb6243 in smp_invlpg_range (addr1=, addr2=) at /usr/src/sys/i386/i386/mp_machdep.c:1323 1323 smp_tlb_shootdown(IPI_INVLRNG, addr1, addr2); (kgdb) list 1318 void 1319 smp_invlpg_range(vm_offset_t addr1, vm_offset_t addr2) 1320 { 1321 1322 if (smp_started) { 1323 smp_tlb_shootdown(IPI_INVLRNG, addr1, addr2); 1324 #ifdef COUNT_XINVLTLB_HITS 1325 ipi_range++; 1326 ipi_range_size += (addr2 - addr1) / PAGE_SIZE; 1327 #endif So tid 100014 wants to send the ipi messages IPI_INVLRNG and waits on the "smp rendezvous" spin lock held by tid 100099. CPU1 idles in thread 100004, nothing special. The fault happens on CPU2 running tid 100005: (kgdb) p/x __pcpu[2] $20 = {pc_curthread = 0xc7ebd000, pc_idlethread = 0xc7ebd000, pc_fpcurthread = 0x0, pc_deadthread = 0x0, pc_curpcb = 0xe437fd40, pc_switchtime = 0x5bbaecb51c, pc_switchticks = 0xd3cf, pc_cpuid = 0x2, pc_allcpu = {stqe_next = 0xc0eade80}, pc_spinlocks = 0x0, pc_cnt = {v_swtch = 0xdfe6, v_trap = 0x2dafc, v_syscall = 0x3c0c0, v_intr = 0xe, v_soft = 0x0, v_vm_faults = 0x2ce48, v_io_faults = 0x64, v_cow_faults = 0x7104, v_cow_optim = 0x5, v_zfod = 0x255b3, v_ozfod = 0x2574, v_swapin = 0x0, v_swapout = 0x0, v_swappgsin = 0x0, v_swappgsout = 0x0, v_vnodein = 0x40a, v_vnodeout = 0x0, v_vnodepgsin = 0xc4b, v_vnodepgsout = 0x0, v_intrans = 0x1, v_reactivated = 0x0, v_pdwakeups = 0x0, v_pdpages = 0x6a, v_tcached = 0x250, v_dfree = 0x0, v_pfree = 0x17689, v_tfree = 0x27abc, v_page_size = 0x0, v_page_count = 0x0, v_free_reserved = 0x0, v_free_target = 0x0, v_free_min = 0x0, v_free_count = 0x0, v_wire_count = 0x0, v_active_count = 0x0, v_inactive_target = 0x0, v_inactive_count = 0x0, v_cache_count = 0x0, v_cache_min = 0x0, v_cache_max = 0x0, v_pageout_free_min = 0x0, v_interrupt_free_min = 0x0, v_free_severe = 0x0, v_forks = 0x2bb, v_vforks = 0xc3c, v_rforks = 0x0, v_kthreads = 0x0, v_forkpages = 0x5cd4, v_vforkpages = 0x230f8, v_rforkpages = 0x0, v_kthreadpages = 0x0}, pc_cp_time = {0x15d, 0x0, 0x260, 0xb, 0x1649}, pc_device = 0xc7fea400, pc_netisr = 0x0, pc_unused1 = 0x0, pc_domain = 0x0, pc_rm_queue = {rmq_next = 0xc0eadb9c, rmq_prev = 0xc0eadb9c}, pc_dynamic = 0x235f1500, pc_monitorbuf = {0x2, 0x0 }, pc_prvspace = 0xc0eada80, pc_curpmap = 0xc0ea3cc0, pc_common_tss = {tss_link = 0x0, tss_esp0 = 0xe437fd30, tss_ss0 = 0x28, tss_esp1 = 0x0, tss_ss1 = 0x0, tss_esp2 = 0x0, tss_ss2 = 0x0, tss_cr3 = 0x0, tss_eip = 0xc0bacac8, tss_eflags = 0x10007, tss_eax = 0xc08f492f, tss_ecx = 0xc8029a20, tss_edx = 0xf0a3ad40, tss_ebx = 0xd3cf, tss_esp = 0xe437f000, tss_ebp = 0xe437fafc, tss_esi = 0xc0e43400, tss_edi = 0xc7ebd000, tss_es = 0x28, tss_cs = 0x20, tss_ss = 0x28, tss_ds = 0x28, tss_fs = 0x8, tss_gs = 0x3b, tss_ldt = 0x0, tss_ioopt = 0x680000}, pc_common_tssd = {sd_lolimit = 0x67, sd_lobase = 0xeadc88, sd_type = 0x9, sd_dpl = 0x0, sd_p = 0x1, sd_hilimit = 0x0, sd_xx = 0x0, sd_def32 = 0x0, sd_gran = 0x0, sd_hibase = 0xc0}, pc_tss_gdt = 0xc0eac01c, pc_fsgs_gdt = 0xc0eabfe4, pc_currentldt = 0x50, pc_acpi_id = 0x1, pc_apic_id = 0x6, pc_private_tss = 0x0, pc_cmci_mask = 0x0, pc_vcpu_id = 0x0, __pad = {0x0 }} (kgdb) p *(struct thread *)0xc7ebd000 $22 = {td_lock = 0xc0e43400, td_proc = 0xc7eba000, td_plist = {tqe_next = 0xc7ebd360, tqe_prev = 0xc7ebca28}, td_runq = {tqe_next = 0x0, tqe_prev = 0x0}, td_slpq = {tqe_next = 0x0, tqe_prev = 0x0}, td_lockq = {tqe_next = 0x0, tqe_prev = 0x0}, td_hash = {le_next = 0x0, le_prev = 0xc7ea3a94}, td_cpuset = 0xc7ea6708, td_sel = 0x0, td_sleepqueue = 0xc7d74d80, td_turnstile = 0xc7d96b00, td_rlqe = 0x0, td_umtxq = 0xc7d6c280, td_tid = 100005, padding1 = {0, 0, 0, 0}, padding2 = {0x0, 0x0, 0x0, 0x0}, td_lend_user_pri = 255 'y"', td_flags = 262180, td_inhibitors = 0, td_pflags = 2097152, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 255 'y"', td_owepreempt = 0 '\0', td_tsqueue = 0 '\0', td_locks = 0, td_rw_rlocks = 0, td_lk_slocks = 0, td_stopsched = 1, td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_ucred = 0xc7d6fb00, td_estcpu = 0, td_slptick = 0, td_blktick = 0, td_swvoltick = 54223, td_cow = 0, td_ru = { ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 3516, ru_nivcsw = 24669}, td_rux = { rux_runtime = 9370350888, rux_uticks = 0, rux_sticks = 423, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, td_incruntime = 116052890114, td_runtime = 125423241002, td_pticks = 5705, td_sticks = 5282, td_iticks = 0, td_uticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_generation = 28185, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_name = "idle: cpu2\000\000\000\000\000\000\000\000\000", td_fpop = 0x0, td_dbgflags = 0, td_dbgksi = {ksi_link = {tqe_next = 0x0, tqe_prev = 0x0}, ksi_info = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = {__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags = 0, ksi_sigq = 0x0}, td_ng_outbound = 0, td_osd = {osd_nslots = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, td_map_def_user = 0x0, td_dbg_forked = 0, td_vp_reserv = 0, td_no_sleeping = 1, td_dom_rr_idx = 0, td_sigmask = {__bits = {0, 0, 0, 0}}, td_rqindex = 0 '\0', td_base_pri = 255 'y"', td_priority = 255 'y"', td_pri_class = 4 '\004', td_user_pri = 120 'x', td_base_user_pri = 120 'x', td_pcb = 0xe437fd40, td_state = TDS_CAN_RUN, td_retval = {0, 0}, td_slpcallout = {c_links = {le = { le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_precision = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_iflags = 16, c_cpu = 0}, td_frame = 0xe437fce8, td_kstack_obj = 0xc17a43a8, td_kstack = 3828867072, td_kstack_pages = 2, td_critnest = 2, td_md = {md_spinlock_count = 2, md_saved_flags = 70, md_spurflt_addr = 0}, td_sched = 0xc7ebd338, td_ar = 0x0, td_lprof = {{lh_first = 0x0}, { lh_first = 0x0}}, td_dtrace = 0xc7d9a600, td_errno = 0, td_vnet = 0x0, td_vnet_lpush = 0x0, td_intr_frame = 0x0, td_rfppwait_p = 0x0, td_ma = 0x0, td_ma_cnt = 0, td_su = 0x0, td_dbg_sc_code = 0, td_dbg_sc_narg = 0, td_emuldata = 0x0, td_sleeptimo = 0, td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_ptrace = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xc7ebd328}, sq_proc = 0xc7eba000, sq_flags = 1}} (kgdb) p/x *(struct pcb*)0xe437fd40 $25 = {pcb_edi = 0xd3cf, pcb_esi = 0xc7ebd000, pcb_ebp = 0xe437fafc, pcb_esp = 0xe437fab0, pcb_ebx = 0xd3cf, pcb_eip = 0xc08f492f, pcb_fsd = {sd_lolimit = 0x0, sd_lobase = 0x0, sd_type = 0x0, sd_dpl = 0x0, sd_p = 0x0, sd_hilimit = 0x0, sd_xx = 0x0, sd_def32 = 0x0, sd_gran = 0x0, sd_hibase = 0x0}, pcb_gsd = { sd_lolimit = 0x0, sd_lobase = 0x0, sd_type = 0x0, sd_dpl = 0x0, sd_p = 0x0, sd_hilimit = 0x0, sd_xx = 0x0, sd_def32 = 0x0, sd_gran = 0x0, sd_hibase = 0x0}, pcb_ds = 0x0, pcb_es = 0x0, pcb_fs = 0x0, pcb_gs = 0x3b, pcb_ss = 0x0, pcb_cr0 = 0x0, pcb_cr2 = 0x0, pcb_cr3 = 0x1424000, pcb_cr4 = 0x0, pcb_dr0 = 0x0, pcb_dr1 = 0x0, pcb_dr2 = 0x0, pcb_dr3 = 0x0, pcb_dr6 = 0x0, pcb_dr7 = 0x0, pcb_gdt = {rd_limit = 0x0, rd_base = 0x0}, pcb_idt = {rd_limit = 0x0, rd_base = 0x0}, pcb_ldt = 0x0, pcb_tr = 0x0, pcb_flags = 0x0, pcb_initial_npxcw = 0x0, pcb_onfault = 0x0, pcb_ext = 0x0, pcb_psl = 0x46, pcb_vm86 = {0x0, 0x0}, pcb_save = 0xe437fe00, pcb_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (kgdb) p/x __pcpu[2]->pc_common_tss $16 = {tss_link = 0x0, tss_esp0 = 0xe437fd30, tss_ss0 = 0x28, tss_esp1 = 0x0, tss_ss1 = 0x0, tss_esp2 = 0x0, tss_ss2 = 0x0, tss_cr3 = 0x0, tss_eip = 0xc0bacac8, tss_e flags = 0x10007, tss_eax = 0xc08f492f, tss_ecx = 0xc8029a20, tss_edx = 0xf0a3ad40, tss_ebx = 0xd3cf, tss_esp = 0xe437f000, tss_ebp = 0xe437fafc, tss_esi = 0xc0e43400, tss_edi = 0xc7ebd000, tss_es = 0x28, tss_cs = 0x20, tss_ss = 0x28, tss_ds = 0x28, tss_fs = 0x8, tss_gs = 0x3b, tss_ldt = 0x0, tss_ioopt = 0x680000} The ddb output on console shows CPU2 has idled in thread 100005, when an IPI_BITMAP_VECTOR message comes in. --- trap 0x17, eip = 0xc0bacac8, esp = 0xe437f000, ebp = 0xe437fafc --- Xpage(c7ebd000,0,608,c08d12a5,c7ebd000,...) at Xpage/frame 0xe437fafc mi_switch(608,0,c0cc08f4,e2,c7ebd000,...) at mi_switch+0x145/frame 0xe437fb34 critical_exit(c7ebd000,0,2) at critical_exit+0x89/frame 0xe437fb50 ipi_bitmap_handler(8,28,28,c7f83200,0,...) at ipi_bitmap_handler+0x6b/frame 0xe437fb70 Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x3d/frame 0xe437fb70 --- interrupt, eip = 0xc0ba87e5, esp = 0xe437fbb8, ebp = 0xe437fbb8 --- acpi_cpu_c1(16600000,16,a65c2a4c,0,c90786c0,...) at acpi_cpu_c1+0x5/frame 0xe437fbb8 db> show thread Thread 100005 at 0xc7ebd000: proc (pid 11): 0xc7eba000 name: idle: cpu2 stack: 0xe437e000-0xe437ffff flags: 0x40024 pflags: 0x200000 state: CAN RUN priority: 255 container lock: sched lock 2 (0xc0e43400) >From kernel stack the above console output is given in more detail: 0xe437f000: 0x00000000 0xc0bacac8 0x00000020 0x00010007 0xe437f010: 0x00000000 0xc0bacac8 0x00000020 0x00010007 .... repeated: tss_eip tss_cs tss_eflags 0xe437fa80: 0x00000000 0xc0bacac8 0x00000020 0x00010007 0xe437fa90: 0x00000000 R8:0xc0bacac8 0x00000020 0x00010007 0xe437faa0: 0x00000000 R7:0xc0bc051c 0x00000020 0x00010007 0xe437fab0: R6:0xc08f492f 0xc7ebd000 0xc8029a20 0xc0e43400 0xe437fac0: 0xe437fb28 0xc08aded5 0xc0e43400 0xc7ebd000 0xe437fad0: 0xc7ebd338 0xc0e43400 0x0000ac69 0xc8029a20 0xe437fae0: 0x00002710 0xc0e43400 0xc7ebd000 0x00000002 0xe437faf0: 0xc7ebd000 0x33cec72a 0x00000608 0xe437fb34 0xe437fb00: R5:0xc08d12a5 0xc7ebd000 0x00000000 0x00000608 0xe437fb10: 0xc08d12a5 0xc7ebd000 0xc7ebd000 0xe437fb28 0xe437fb20: 0xbaecb51c 0xc7ebd000 0xc7ebd000 0x00000002 0xe437fb30: 0x00000002 0xe437fb50 R4:0xc08ced89 0x00000608 0xe437fb40: 0x00000000 0xc0cc08f4 0x000000e2 0xc7ebd000 0xe437fb50: 0xe437fb70 R3:0xc0bb659b 0xc7ebd000 0x00000000 0xe437fb60: 0x00000002 0x00000000 0xc7f83200 0xc7f8321c 0xe437fb70: 0xe437fbb8 R2:0xc0bad42d 0x00000008 0x00000028 0xe437fb80: 0x00000028 0xc7f83200 0x00000000 0xe437fbb8 0xe437fb90: 0xe437fba4 0xc7f8321c 0x0000005b 0x00000000 0xe437fba0: 0xbaebe810 0x00000000 0x00000000 R1:0xc0ba87e5 0xe437fbb0: 0x00000020 0x00000246 0xe437fbf8 R0:0xc0549d3a 0xe437fbc0: 0x16600000 0x00000016 0xa65c2a4c 0x00000000 0xe437fbd0: 0xc90786c0 0xbaebe810 0x0000005b 0x00000002 0xe437fbe0: 0x00000001 0x00000021 0x00000008 0xc0eadc00 0xe437fbf0: 0xffffffff 0x00000001 0xe437fc0c 0xc0bb0d8f R0: return address frame 0xe437fbf8 (kgdb) list *0xc0549d3a 0xc0549d3a is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:1027). 1022 * we are called inside critical section, delaying context switch. 1023 */ 1024 if (cx_next->type == ACPI_STATE_C1) { 1025 cputicks = cpu_ticks(); 1026 acpi_cpu_c1(); 1027 end_time = ((cpu_ticks() - cputicks) << 20) / cpu_tickrate(); 1028 if (curthread->td_critnest == 0) 1029 end_time = min(end_time, 500000 / hz); 1030 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + end_time) / 4; 1031 return; R1: address after hlt (kgdb) list *0xc0ba87e5 0xc0ba87e5 is in acpi_cpu_c1 (/usr/src/sys/i386/acpica/acpi_machdep.c:115). 110 void 111 acpi_cpu_c1() 112 { 113 114 __asm __volatile("sti; hlt"); 115 } 116 117 /* 118 * Support for mapping ACPI tables during early boot. This abuses the 119 * crashdump map because the kernel cannot allocate KVA in R2: return address frame 0xe437fbb8 (kgdb) list *0xc0bad42d 0xc0bad42d is at apic_vector.s:242. 237 238 FAKE_MCOUNT(TF_EIP(%esp)) 239 240 call ipi_bitmap_handler 241 MEXITCOUNT 242 jmp doreti 243 #endif 244 /* 245 * Executed by a CPU when it receives an IPI_STOP from another CPU. 246 */ R3: return address frame 0xe437fb70 (kgdb) list *0xc0bb659b 0xc0bb659b is in ipi_bitmap_handler (/usr/src/sys/i386/i386/mp_machdep.c:1403). 1398 hardclockintr(); 1399 } 1400 td->td_intr_frame = oldframe; 1401 td->td_intr_nesting_level--; 1402 critical_exit(); 1403 } 1404 1405 /* 1406 * send an IPI to a set of cpus. 1407 */ R4: return address frame 0xe437fb50 (kgdb) list *0xc08ced89 0xc08ced89 is in critical_exit (/usr/src/sys/kern/kern_switch.c:234). 229 if (TD_IS_IDLETHREAD(td)) 230 flags |= SWT_IDLE; 231 else 232 flags |= SWT_OWEPREEMPT; 233 mi_switch(flags, NULL); 234 thread_unlock(td); 235 } 236 } else 237 td->td_critnest--; R5: return address frame 0xe437fb34: Call "sched_switch(td, newtd, mtx)" with td=0xc7ebd000, newtd=0x00000000, mtx=0x00000608 (kgdb) list *0xc08d12a5 0xc08d12a5 is in mi_switch (/usr/src/sys/kern/kern_synch.c:480). 473 sched_switch(td, newtd, flags); 474 CTR4(KTR_PROC, "mi_switch: new thread %ld (td_sched %p, pid %ld, %s)", 475 td->td_tid, td->td_sched, td->td_proc->p_pid, td->td_name); 476 477 /* 478 * If the last thread was exiting, finish cleaning it up. 479 */ 480 if ((td = PCPU_GET(deadthread))) { 481 PCPU_SET(deadthread, NULL); 482 thread_stash(td); 483 } 484 } R6: return address frame unknown (overwritten on stack) Call "cpu_switch(td, newtd, mtx)" with td=0xc7ebd000, newtd=0xc8029a20, mtx=0xc0e43400 (=td_lock) (kgdb) list *0xc08f492f 0xc08f492f is in sched_switch (/usr/src/sys/kern/sched_ule.c:1956). 1950 cpu_switch(td, newtd, mtx); 1951 /* 1952 * We may return from cpu_switch on a different cpu. However, 1953 * we always return with td_lock pointing to the current cpu's 1954 * run queue lock. 1955 */ 1956 cpuid = PCPU_GET(cpuid); 1957 tdq = TDQ_CPU(cpuid); 1958 lock_profile_obtain_lock_success( 1959 &TDQ_LOCKPTR(tdq)->lock_object, 0, 0, __FILE__, __LINE__); 1960 (kgdb) p (*(struct thread*)0xc8029a20)->td_name $5 = "irq16: uhci0\000\000\000\000\000\000\000" (kgdb) p (*(struct thread*)0xc8029a20)->td_tid $3 = 100030 R7: (kgdb) list *0xc0bc051c 0xc0bc051c is at /usr/src/sys/i386/i386/swtch.s:176. 171 jz badsw3 /* no, panic */ 172 #endif 173 movl TD_PCB(%ecx),%edx 174 175 /* switch address space */ 176 movl PCB_CR3(%edx),%eax 177 #if defined(PAE) || defined(PAE_TABLES) 178 cmpl %eax,IdlePDPT /* Kernel address space? */ 179 #else 180 cmpl %eax,IdlePTD /* Kernel address space? */ R8: (kgdb) list *0xc0bacac8 0xc0bacac8 is at /usr/src/sys/i386/i386/exception.s:135. 130 IDTVEC(stk) 131 TRAP(T_STKFLT) 132 IDTVEC(prot) 133 TRAP(T_PROTFLT) 134 IDTVEC(page) 135 TRAP(T_PAGEFLT) 136 IDTVEC(mchk) 137 pushl $0; TRAP(T_MCHK) 138 IDTVEC(rsvd) 139 pushl $0; TRAP(T_RESERVED) On the stack we have 0xe437faa0: 0x00000000 R7:0xc0bc051c 0x00000020 0x00010007 so there is an exception on the instruction "movl PCB_CR3(%edx),%eax" in function cpu_switch(). The next stack entries indicates a lot of page faults, but the "double fault" happens not until the page boundary at 0xe437f000 is reached. I do not really understand this, but it seems to me that the thread "panic: double fault with 11.0-CURRENT r258504" on freebsd-stable describes a similar problem. However I have an Intel CPU: (kgdb) p/x cpu_vendor_id $3 = 0x8086 (kgdb) p/x cpu_id $4 = 0xf29 (kgdb) p/x cpu_feature $5 = 0xbfebfbff (kgdb) p/x cpu_feature2 $6 = 0x4400 kernel: Copyright (c) 1992-2017 The FreeBSD Project. kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 kernel: The Regents of the University of California. All rights reserved. kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. kernel: FreeBSD 10.3-STABLE #2 r317936: Wed Sep 13 10:24:12 CEST 2017 kernel: root@dssresv3.incore:/usr/obj/usr/src/sys/SERVER32 i386 kernel: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 kernel: CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3189.77-MHz 686-class CPU) kernel: Origin="GenuineIntel" Id=0xf25 Family=0xf Model=0x2 Stepping=5 kernel: Features=0xbfebfbff kernel: Features2=0x4400 kernel: real memory = 4294967296 (4096 MB) kernel: avail memory = 3936845824 (3754 MB) kernel: Event timer "LAPIC" quality 400 kernel: ACPI APIC Table: kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs kernel: FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads kernel: cpu0 (BSP): APIC ID: 0 kernel: cpu1 (AP/HT): APIC ID: 1 kernel: cpu2 (AP): APIC ID: 6 kernel: cpu3 (AP/HT): APIC ID: 7 kernel: random: initialized kernel: ioapic0 irqs 0-23 on motherboard kernel: ioapic1 irqs 24-47 on motherboard kernel: ioapic2 irqs 48-71 on motherboard kernel: lapic0: Forcing LINT1 to edge trigger I can not reproduce the problem, last double fault I saw was some years ago on identical hardware (Bug 194225 double fault after page fault on 8.4 Stable). Andreas Longwitz From owner-freebsd-hackers@freebsd.org Wed Nov 1 09:26:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C740E5150C for ; Wed, 1 Nov 2017 09:26:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7AE664910 for ; Wed, 1 Nov 2017 09:26:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vA19QKFL053725 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Nov 2017 11:26:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vA19QKFL053725 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vA19QJuT053724; Wed, 1 Nov 2017 11:26:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Nov 2017 11:26:19 +0200 From: Konstantin Belousov To: Andreas Longwitz Cc: freebsd-hackers@freebsd.org Subject: Re: double fault on 10.3-Stable i386 during installworld Message-ID: <20171101092619.GJ2566@kib.kiev.ua> References: <59D11664.1060206@incore.de> <20171001180943.GO95911@kib.kiev.ua> <59F910C5.8020709@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59F910C5.8020709@incore.de> User-Agent: Mutt/1.9.1 (2017-09-22) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 09:26:26 -0000 On Wed, Nov 01, 2017 at 01:09:41AM +0100, Andreas Longwitz wrote: > On the stack we have > > 0xe437faa0: 0x00000000 R7:0xc0bc051c 0x00000020 0x00010007 > > so there is an exception on the instruction "movl PCB_CR3(%edx),%eax" > in function cpu_switch(). The next stack entries indicates a lot of page > faults, but the "double fault" happens not until the page boundary at > 0xe437f000 is reached. I do not really understand this, but it seems to > me that the thread Can you try to recover the %ecx, %edx values for the faulted frame ? Note that %ecx is loaded from the on-stack argument. Do you have latest CPU microcode loaded ? Your machine is very old, I believe this is P4 class processor, am I right ? Sure if pcb access faults, the system is in very broken state and since an attempt to handle the fault causes a new fault for pcb access, it recurses and dies due to the stack overflow. From owner-freebsd-hackers@freebsd.org Thu Nov 2 21:39:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DA69E6389D for ; Thu, 2 Nov 2017 21:39:50 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB706ABF8 for ; Thu, 2 Nov 2017 21:39:50 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7634FE6389C; Thu, 2 Nov 2017 21:39:50 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73F53E6389B for ; Thu, 2 Nov 2017 21:39:50 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0B566ABF7 for ; Thu, 2 Nov 2017 21:39:49 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id m72so1588354wmc.1 for ; Thu, 02 Nov 2017 14:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=NB3nobPerJNPNietvbnamgVXUnRbHPAGFA6F3Ag2nF8=; b=tyM8qLtzRX+W0Vzr3WRRxiOCZ+IyM8n2hjALmJ94sh86mOEBctc0e6pD8AvtAofg1y HQA+W8DYNyNW/TKzzqNo1+Kp/GgemQz+d13P/CYMgHcDnd/HilUmDzt66PkjUrhCWM9Y iUS8g9PDbN9X5yxn+0R0n+BmZCdecAekK5vVcyDCDZdGvQ7Lo52dxYmsJ7v/x6xGjkl3 e4bkiPaKGt3LD+mifAf3jvIRbqoTZytZQ+y8uMI3/PArhiJlokEdxzrHS16j4kQIgnoI RdUfKWXnOb8F1wsel0n4N5xEu7LJ4iKIJx8HOwMnEAHYO6Jmk0OhI/FDVTe6KKyqy64b VQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=NB3nobPerJNPNietvbnamgVXUnRbHPAGFA6F3Ag2nF8=; b=PBqQl44X8hA0FzlbVne+s/fQZsc6WmCkYA9ZZ0ptvqrfQU1ivC8mrRbtq89SERFQQt oN/cgBDr3Z0m7TU65knA5rrjEZzbZm9r3cm6ZrJ1eskpofCnpgvA4ce9IuwC1JfjmV0R OJJjSaaIA/FcsA+Cn4/jHtwiXJc2BQIuJOiN068MtBf+Rfy6NHGDKdmPOQyZkAX3f7Fl jkdJbwakPym5IU4o8+tuk3vFeDb32CCGOlgpcn6TYkJj2suRcNZw5xYv/475qUZi0wy0 YOrca7dyTupGPWOjL+O6F1hSVOKLlwD90AJu505lyT0va/B9/EWuYJvR1bESAPxxuIsY bUeQ== X-Gm-Message-State: AMCzsaWWWzaW/5yJLtTEut9yDD+fqzri41VDJqLqK1fXHtGTWCzl7zLj evjgG6+KqUlSEY3jhrtHj5HKhA== X-Google-Smtp-Source: ABhQp+TpGt89qjUtuJHK0xil2b3NecHYfJRfypLP3OGxYYQEZMh2wTp6FlhOf/NUBhnlV7pFnkMzPA== X-Received: by 10.80.163.136 with SMTP id s8mr5878888edb.302.1509658788252; Thu, 02 Nov 2017 14:39:48 -0700 (PDT) Received: from localhost ([213.149.53.40]) by smtp.gmail.com with ESMTPSA id t11sm3682716edh.63.2017.11.02.14.39.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 14:39:47 -0700 (PDT) Date: Thu, 2 Nov 2017 22:39:40 +0100 From: To: Subject: 10.* => 11.* disabled colored prompt (/bin/sh) Message-ID: <20171102223940.00001f82@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 21:39:50 -0000 So, after I migrated to REL 11.0 & later 11.1 (i386) my prompt of /bin/sh isn't colorized anymore. Instead literal string is displayed. At prompt: [31;5mSTRING[m echo $PS1 STRING ... is flashing in red. "Somebody" (Jilles?!) did "something" to /bin/sh. Domagoj From owner-freebsd-hackers@freebsd.org Thu Nov 2 22:44:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8514E647E4 for ; Thu, 2 Nov 2017 22:44:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-150.reflexion.net [208.70.210.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6536C9A6 for ; Thu, 2 Nov 2017 22:44:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4066 invoked from network); 2 Nov 2017 22:44:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Nov 2017 22:44:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 02 Nov 2017 18:44:42 -0400 (EDT) Received: (qmail 21718 invoked from network); 2 Nov 2017 22:44:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Nov 2017 22:44:41 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 41B25EC94E6; Thu, 2 Nov 2017 15:44:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools Message-Id: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> Date: Thu, 2 Nov 2017 15:44:40 -0700 Cc: Bryan Drewery To: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 22:44:50 -0000 > Author: bdrewery > Date: Thu Nov 2 22:23:00 2017 > New Revision: 325347 > URL:=20 > https://svnweb.freebsd.org/changeset/base/325347 >=20 >=20 > Log: > Something is very wrong >=20 > Modified: > head/Makefile >=20 > Modified: head/Makefile > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) > +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) > @@ -1,3 +1,4 @@ > +.error Bad revision, please wait for a fix in head > # > # $FreeBSD$ > # I just happened to have started a cross build before this showed up based on -r325332 . It got: --- clang-tblgen.full --- c++: error: no such file or directory: = '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/= clang/libllvmminimal/libllvmminimal.a' *** [clang-tblgen.full] Error code 1 But find shows: # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name = "libllvmminimal*" -print | more = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta Comparing side-by-side shows obj-cross-tools vs. obj-bootstrap-tools : = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Nov 3 00:30:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CF1EE66586; Fri, 3 Nov 2017 00:30:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C1AF6F3F3; Fri, 3 Nov 2017 00:30:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 6240F14DE1; Fri, 3 Nov 2017 00:30:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 58E1A8AE4; Fri, 3 Nov 2017 00:30:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id gp51ZhQqtdKG; Fri, 3 Nov 2017 00:30:21 +0000 (UTC) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 68ADC8ADD To: Mark Millard , FreeBSD Toolchain , freebsd-hackers , FreeBSD Current References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Thu, 2 Nov 2017 17:30:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qrq8DvtoUV5tu1PN5lkApOG2X74FTHLmF" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 00:30:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qrq8DvtoUV5tu1PN5lkApOG2X74FTHLmF Content-Type: multipart/mixed; boundary="cUqMJNwpsd8dWLOGNh6NqqSsT6VfseP2I"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Message-ID: Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> In-Reply-To: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> --cUqMJNwpsd8dWLOGNh6NqqSsT6VfseP2I Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/17 3:44 PM, Mark Millard wrote: >> Author: bdrewery >> Date: Thu Nov 2 22:23:00 2017 >> New Revision: 325347 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/325347 >> >> >> Log: >> Something is very wrong >> >> Modified: >> head/Makefile >> >> Modified: head/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >> @@ -1,3 +1,4 @@ >> +.error Bad revision, please wait for a fix in head >> # >> # $FreeBSD$ >> # >=20 > I just happened to have started a cross build before > this showed up based on -r325332 . It got: >=20 > --- clang-tblgen.full --- > c++: error: no such file or directory: '/usr/obj/bpim3_clang/arm.armv7/= usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmmin= imal.a' > *** [clang-tblgen.full] Error code 1 Someone else reported this one as well but I have not been able to reproduce it yet. I've tweaked the commit causing it though, r325329. Fixed in r325350. >=20 > But find shows: >=20 > # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libllvmm= inimal*" -print | more > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tool= s/lib/clang/libllvmminimal > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tool= s/lib/clang/libllvmminimal/libllvmminimal.a > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tool= s/lib/clang/libllvmminimal/libllvmminimal.a.meta >=20 > Comparing side-by-side shows obj-cross-tools vs. > obj-bootstrap-tools : >=20 > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/li= b/clang/libllvmminimal/libllvmminimal.a > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tool= s/lib/clang/libllvmminimal/libllvmminimal.a >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --cUqMJNwpsd8dWLOGNh6NqqSsT6VfseP2I-- --Qrq8DvtoUV5tu1PN5lkApOG2X74FTHLmF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAln7uIgACgkQNddxu25G l8+gVQgAy8F3o6wYr1bZ81xX58KcGXOCqQkNUNqQi0RNUSGiQJwo7aXhdB/XV0jY xcO8oRqeGAVhlv+IBTS7gcGBzsHxQZhm7lgnE8u5r/u/iqyb+LzW+B+XF56T8wxq Uymjm9NP+7z2i9thJEoa0QZhwVi/TXhgzZCAObJrnK9miqaYi3jD//xI/sPs6j4x uiy/p3UYk/NTRZqw1UKdDaQOCdCLwzZEduenl5iiSJZOqx4eY4U+Ai/WC35kDXK0 RwT1kZkSMFG/3yAUDRZ7RI/WFT+ymNKnHJqo0d5Regxp64wolc3Ck+ef2cXFszu+ 4LjMxnudnXR11+DbuIjAgorJ/Ce68w== =lR3v -----END PGP SIGNATURE----- --Qrq8DvtoUV5tu1PN5lkApOG2X74FTHLmF-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 01:25:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53782E675F3; Fri, 3 Nov 2017 01:25:43 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D82170B87; Fri, 3 Nov 2017 01:25:43 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 495B715464; Fri, 3 Nov 2017 01:25:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 3781B8C13; Fri, 3 Nov 2017 01:25:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id LG-q095ng8gm; Fri, 3 Nov 2017 01:25:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com F15978C05 From: Bryan Drewery Mime-Version: 1.0 (1.0) Subject: Head build unsafe for /etc today Message-Id: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> Date: Thu, 2 Nov 2017 18:25:24 -0700 To: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current X-Mailer: iPhone Mail (15A402) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 01:25:43 -0000 On Nov 2, 2017, at 15:44, Mark Millard wrote: >> Author: bdrewery >> Date: Thu Nov 2 22:23:00 2017 >> New Revision: 325347 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/325347 >>=20 >>=20 >> Log: >> Something is very wrong Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN= . In the =E2=80=9Cclean=E2=80=9D builds it was removing /sys/boot and /etc, bu= t nothing else in /. The problems have been fixed in head as of r325351. The problem came in r325330. This was in head for ~10 hours. Sorry for the trouble. >>=20 >> Modified: >> head/Makefile >>=20 >> Modified: head/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >> @@ -1,3 +1,4 @@ >> +.error Bad revision, please wait for a fix in head >> # >> # $FreeBSD$ >> # >=20 > I just happened to have started a cross build before > this showed up based on -r325332 . It got: >=20 > --- clang-tblgen.full --- > c++: error: no such file or directory: '/usr/obj/bpim3_clang/arm.armv7/usr= /src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a= ' > *** [clang-tblgen.full] Error code 1 >=20 > But find shows: >=20 > # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libllvmmini= mal*" -print | more > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta >=20 > Comparing side-by-side shows obj-cross-tools vs. > obj-bootstrap-tools : >=20 > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a > /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 From owner-freebsd-hackers@freebsd.org Fri Nov 3 01:49:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9543EE67DA6; Fri, 3 Nov 2017 01:49:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7559171651; Fri, 3 Nov 2017 01:49:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vA31n7KI088560 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2017 18:49:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vA31n7Og088559; Thu, 2 Nov 2017 18:49:07 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Nov 2017 18:49:07 -0700 From: Steve Kargl To: Bryan Drewery Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Subject: Re: Head build unsafe for /etc today Message-ID: <20171103014907.GA88522@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 01:49:13 -0000 On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: > > On Nov 2, 2017, at 15:44, Mark Millard wrote: > > >> Author: bdrewery > >> Date: Thu Nov 2 22:23:00 2017 > >> New Revision: 325347 > >> URL: > >> https://svnweb.freebsd.org/changeset/base/325347 > >> > >> > >> Log: > >> Something is very wrong > > > Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN. You're making changes to the build infrastructure and you're not properly testing it before committing? This is beyond pointyhat material. -- Steve From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:08:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB99FE68264; Fri, 3 Nov 2017 02:08:59 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84EED71E63; Fri, 3 Nov 2017 02:08:59 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C2F83159F9; Fri, 3 Nov 2017 02:08:58 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id E2D9F8CDA; Fri, 3 Nov 2017 02:08:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id NI2NPZ_HYrkt; Fri, 3 Nov 2017 02:08:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com DC3778CD7 Mime-Version: 1.0 (1.0) Subject: Re: Head build unsafe for /etc today From: Bryan Drewery X-Mailer: iPhone Mail (15A402) In-Reply-To: <20171103014907.GA88522@troutmask.apl.washington.edu> Date: Thu, 2 Nov 2017 19:08:50 -0700 Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:08:59 -0000 > On Nov 2, 2017, at 18:49, Steve Kargl w= rote: >=20 >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: >>=20 >> On Nov 2, 2017, at 15:44, Mark Millard wrote: >>=20 >>>> Author: bdrewery >>>> Date: Thu Nov 2 22:23:00 2017 >>>> New Revision: 325347 >>>> URL:=20 >>>> https://svnweb.freebsd.org/changeset/base/325347 >>>>=20 >>>>=20 >>>> Log: >>>> Something is very wrong >>=20 >>=20 >> Unfortunately I only test with META_MODE these days which implies -DNO_CL= EAN. >=20 > You're making changes to the build infrastructure and you're > not properly testing it before committing? This is beyond > pointyhat material.=20 I ran 2 universes, dozens of buildworlds and buildkernels, dozens of install= world and installkernel, several xdev and native-xtools, several full DIRDEP= S_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, tested s= everal targets together, ran various special case tests for submakes, played= around with a ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked o= bjdirs special, ran it through my work repro a few times, did special testin= g in rescue/, and had a volunteer test release. In the process I found a b= make bug, GPL_DTC build bug and several others I don=E2=80=99t recall from t= he bus. What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because I forgot it= even exists. I=E2=80=99ve wanted to remove it for a year. I also forgot to t= est buildenv. By the way the bug ran into here was 3-4 years old and I avoided the exact c= ase in some new code but missed that the problem was already existing subtly= in bsd.obj.mk. Having said all of that, I certainly don=E2=80=99t do so much testing normal= ly but these changes warranted the time I put in. >=20 > --=20 > Steve From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:23:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C34DE68A8C; Fri, 3 Nov 2017 02:23:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E17C4727EC; Fri, 3 Nov 2017 02:23:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vA32NRsp088749 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2017 19:23:27 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vA32NRCr088748; Thu, 2 Nov 2017 19:23:27 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Nov 2017 19:23:27 -0700 From: Steve Kargl To: Bryan Drewery Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Subject: Re: Head build unsafe for /etc today Message-ID: <20171103022327.GA88659@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:23:29 -0000 On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > > > > On Nov 2, 2017, at 18:49, Steve Kargl wrote: > > > >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: > >> > >> On Nov 2, 2017, at 15:44, Mark Millard wrote: > >> > >>>> Author: bdrewery > >>>> Date: Thu Nov 2 22:23:00 2017 > >>>> New Revision: 325347 > >>>> URL: > >>>> https://svnweb.freebsd.org/changeset/base/325347 > >>>> > >>>> > >>>> Log: > >>>> Something is very wrong > >> > >> > >> Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN. > > > > You're making changes to the build infrastructure and you're > > not properly testing it before committing? This is beyond > > pointyhat material. > > I ran 2 universes, dozens of buildworlds and buildkernels, dozens of installworld and installkernel, several xdev and native-xtools, several full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, tested several targets together, ran various special case tests for submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs special, ran it through my work repro a few times, did special testing in rescue/, and had a volunteer test release. In the process I found a bmake bug, GPL_DTC build bug and several others I don’t recall from the bus. > > What I missed was the “clean” buildworld because I forgot it even exists. I’ve wanted to remove it for a year. I also forgot to test buildenv. > If you did all the above under META_MODE, then no you did not buildworld and buildkernel and all the other stuff you claim. If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent in whatever jail you use, then you're not properly testing your changes to the build infrastructure. As you have demonstrated, Makefile, Makefile.inc1, and the *.mk files are sufficiently complicated that proper testing should be done, and proper testing means one doesn't takes shortcuts. -- Steve From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:36:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8F7CE68EC1; Fri, 3 Nov 2017 02:36:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 942F372DE3; Fri, 3 Nov 2017 02:36:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A981215E28; Fri, 3 Nov 2017 02:36:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 3 Nov 2017 02:36:51 +0000 From: Glen Barber To: Steve Kargl Cc: Bryan Drewery , FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Subject: Re: Head build unsafe for /etc today Message-ID: <20171103023651.GC34123@FreeBSD.org> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <20171103022327.GA88659@troutmask.apl.washington.edu> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:36:55 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote: > On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > > > On Nov 2, 2017, at 18:49, Steve Kargl wrote: > > > You're making changes to the build infrastructure and you're > > > not properly testing it before committing? This is beyond > > > pointyhat material.=20 > >=20 > > I ran 2 universes, dozens of buildworlds and buildkernels, > > dozens of installworld and installkernel, several xdev and > > native-xtools, several full DIRDEPS_BUILD builds and bootstraps, > > ran subdir builds, ran subdir cleans, tested several targets together, > > ran various special case tests for submakes, played around with a > > ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs > > special, ran it through my work repro a few times, did special > > testing in rescue/, and had a volunteer test release. In the process > > I found a bmake bug, GPL_DTC build bug and several others I don=E2=80= =99t > > recall from the bus. > >=20 > > What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because I forg= ot it > > even exists. I=E2=80=99ve wanted to remove it for a year. I also forgot= to > > test buildenv. > >=20 >=20 > If you did all the above under META_MODE, then no you did not=20 > buildworld and buildkernel and all the other stuff you claim. > If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent > in whatever jail you use, then you're not properly testing=20 > your changes to the build infrastructure. I did test this, personally, and missed it. > As you have demonstrated, > Makefile, Makefile.inc1, and the *.mk files are sufficiently=20 > complicated that proper testing should be done, and proper=20 > testing means one doesn't takes shortcuts. >=20 Mistakes happen. Things sometimes get accidentally missed. Glen --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAln71j4ACgkQAxRYpUeP 4pNCcg/+MYE8KZ7MuCX+sO+Alc0QISpF5JosxGS8FukLMEb1oKM14ad9xChSRKHZ fHgm+1yehr5ENrRBGw76RMsAQBt/UjQjHTVtA/x9wU+sWcSgcRMp5BQzur7WM/Yf R5fiau5YvFFJdNm6igrh2hSEgNSp7WznSGOm6bcIk8rS1dxBsRvjLcdXa1HBgudY uR3mysZyy3pG1ZPh7k3Wtv+4eziDnkffv5rJQBVgCPHFu3jT67ctPq8lu2hEeyCk uxA3pISrqTFvdIczKXkUpcL9yaECCth/Lstcr68e0byKx4KvdyRW9/7x7NCNYes8 EXGiFu5YXBmdLr9onQ0LybkhGFjIo6xfRf+r8q9ge8XNO9Ar7D2UeyU4tiJx3g5L xHn/PzkkLg1f4Q8Pd1r86vXNBAI6CJmDQEpBR2ascT3Q7bPSLcPXuDE1VXpeoEeN Py0fjP41BdHli2XJo0jc7qBxsX8pQ5BjR9kbx3UBjUTZDORHRSj7THEkwv6kQgHx UCVIeAepty402yQJgBzgar2HQ+nd9zznliTPtygn42zaIOvTAWqAvYP+7DGBw0cR bS6TOXgt0MBDR5p1Hf9EdYeB5n4owwcsU0V2tBDC/uvoE8w6r9Gw8dH6GIzkXp1c fODMpzsoGg83i8MgslbelsQQKQrCZiywsByZkrlJLZ8tkZAZjlg= =DwAh -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:41:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67300E69221; Fri, 3 Nov 2017 02:41:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 411577329B; Fri, 3 Nov 2017 02:41:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 86D1215FB6; Fri, 3 Nov 2017 02:41:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 712E88E48; Fri, 3 Nov 2017 02:41:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id zildTF2mjAJd; Fri, 3 Nov 2017 02:41:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 252538E45 Mime-Version: 1.0 (1.0) Subject: Re: Head build unsafe for /etc today From: Bryan Drewery X-Mailer: iPhone Mail (15A402) In-Reply-To: <20171103022327.GA88659@troutmask.apl.washington.edu> Date: Thu, 2 Nov 2017 19:41:21 -0700 Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:41:46 -0000 > On Nov 2, 2017, at 19:23, Steve Kargl w= rote: >=20 >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: >>=20 >>=20 >>>> On Nov 2, 2017, at 18:49, Steve Kargl wrote: >>>>=20 >>>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: >>>>=20 >>>> On Nov 2, 2017, at 15:44, Mark Millard wrote: >>>>=20 >>>>>> Author: bdrewery >>>>>> Date: Thu Nov 2 22:23:00 2017 >>>>>> New Revision: 325347 >>>>>> URL:=20 >>>>>> https://svnweb.freebsd.org/changeset/base/325347 >>>>>>=20 >>>>>>=20 >>>>>> Log: >>>>>> Something is very wrong >>>>=20 >>>>=20 >>>> Unfortunately I only test with META_MODE these days which implies -DNO_= CLEAN. >>>=20 >>> You're making changes to the build infrastructure and you're >>> not properly testing it before committing? This is beyond >>> pointyhat material.=20 >>=20 >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of inst= allworld and installkernel, several xdev and native-xtools, several full DIR= DEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, test= ed several targets together, ran various special case tests for submakes, pl= ayed around with a ton of MAKEOBJDIRPREFIX cases, handled and tested symlink= ed objdirs special, ran it through my work repro a few times, did special te= sting in rescue/, and had a volunteer test release. In the process I found= a bmake bug, GPL_DTC build bug and several others I don=E2=80=99t recall fr= om the bus. >>=20 >> What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because I forgot= it even exists. I=E2=80=99ve wanted to remove it for a year. I also forgot t= o test buildenv. >>=20 >=20 > If you did all the above under META_MODE, then no you did not=20 > buildworld and buildkernel and all the other stuff you claim. Are you accusing me of lying? > If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent > in whatever jail you use, then you're not properly testing=20 > your changes to the build I did that probably 100 times. And that isn=E2=80=99t even =E2=80=9Cthe prop= er test=E2=80=9D. Both clean and incremental are needed which I did. zfs sna= pshots help a lot there. I just never ran =E2=80=9C_cleanobj=E2=80=9D which d= oes a full tree walk of clean. But I ran make clean in some subdirs many tim= es. > infrastructure. As you have demonstrated, > Makefile, Makefile.inc1, and the *.mk files are sufficiently=20 > complicated that proper testing > should be done, and proper=20 > testing means one doesn't takes shortcuts. I took 0 shortcuts. As I said I *forgot* that case, among hundreds of cases.= You=E2=80=99re welcome to do this work if you want. I guarantee you would no= t have tested even half of what I tested.=20 Hey can you fix universe to only build clang once please? I=E2=80=99ve been w= orking up to that but I think you=E2=80=99re best to do it. >=20 > --=20 > Steve From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:43:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1013AE693F4; Fri, 3 Nov 2017 02:43:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B61AD735BF; Fri, 3 Nov 2017 02:43:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 02803160F6; Fri, 3 Nov 2017 02:43:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 2C4D58E5E; Fri, 3 Nov 2017 02:43:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Hm_3bVnWKcT5; Fri, 3 Nov 2017 02:43:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 497448E5B Mime-Version: 1.0 (1.0) Subject: Re: Head build unsafe for /etc today From: Bryan Drewery X-Mailer: iPhone Mail (15A402) In-Reply-To: <20171103023651.GC34123@FreeBSD.org> Date: Thu, 2 Nov 2017 19:43:20 -0700 Cc: Steve Kargl , FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <20171103023651.GC34123@FreeBSD.org> To: Glen Barber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:43:46 -0000 > On Nov 2, 2017, at 19:36, Glen Barber wrote: >=20 >> On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote: >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: >>>> On Nov 2, 2017, at 18:49, Steve Kargl wrote: >>>> You're making changes to the build infrastructure and you're >>>> not properly testing it before committing? This is beyond >>>> pointyhat material.=20 >>>=20 >>> I ran 2 universes, dozens of buildworlds and buildkernels, >>> dozens of installworld and installkernel, several xdev and >>> native-xtools, several full DIRDEPS_BUILD builds and bootstraps, >>> ran subdir builds, ran subdir cleans, tested several targets together, >>> ran various special case tests for submakes, played around with a >>> ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs >>> special, ran it through my work repro a few times, did special >>> testing in rescue/, and had a volunteer test release. In the process >>> I found a bmake bug, GPL_DTC build bug and several others I don=E2=80=99= t >>> recall from the bus. >>>=20 >>> What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because I forgo= t it >>> even exists. I=E2=80=99ve wanted to remove it for a year. I also forgot t= o >>> test buildenv. >>>=20 >>=20 >> If you did all the above under META_MODE, then no you did not=20 >> buildworld and buildkernel and all the other stuff you claim. >> If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent >> in whatever jail you use, then you're not properly testing=20 >> your changes to the build infrastructure. >=20 > I did test this, personally, and missed it. To be fair you didn=E2=80=99t test the AUTO_OBJ piece but did test the much m= ore riskier changes to objdir handling. Thanks for that. >> As you have demonstrated, >> Makefile, Makefile.inc1, and the *.mk files are sufficiently=20 >> complicated that proper testing should be done, and proper=20 >> testing means one doesn't takes shortcuts. >>=20 >=20 > Mistakes happen. Things sometimes get accidentally missed. >=20 > Glen >=20 From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:46:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8145E695DE for ; Fri, 3 Nov 2017 02:46:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78E8E7385E for ; Fri, 3 Nov 2017 02:46:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id 101so3340619ioj.3 for ; Thu, 02 Nov 2017 19:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=itWTTX9c3DyQmal3w4PwTj84lYg35nAVNJVnPqYrFdw=; b=oAOF9SJL1PAZuUivSpzKa29PMXgDSiW99bJo7hvlBvMjqIWwrDFXOb9/dpQ1dgwUPx /EjWtRsILwFx5ahr9ojOcaoF11FxD9y8yrq6vlBYhlSQAb1zN2wnljj4/bsA4G5Rq177 IC9YqvnuK9ELUlgsZKO56LOAN6JfcCKe0NwUJZRF+p0Z6ivyNSr/zohES6O6ixB/r4bI D7J98aktOVdW7ppYlobeE24b1/FOTa9dhKuP5hVkrR+OSemZZ5mH5s/dwP36ZaZRSNWs OnnIBowy/eklMnVSj/HsOAfCysfEiEgtBCWiMHTjea3T1WaIhJ8vmeF+xIi9K+EbvsZ8 z/nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=itWTTX9c3DyQmal3w4PwTj84lYg35nAVNJVnPqYrFdw=; b=DFZvea7JgdVrK1resbMwOAE9067TTp37hxgrhol0RGNQjUrv40QIXV2Hrh/aBFVUlM V8qfRbxOGenwVEI0j26CVQK9y3T5gYMS0PSSLtAGmBxS2LmhWSdWZKED/cjNSBYwFTVt ff89N8cftesdROBZ6LAkNgkqR6k5almmSoqVxXnL0i964HsUUYWBZlq/PYNjGEJiOLGY 2RyKvBB45tpltu2OOQ92v6b/ysy4+MdO6DM8glCHm90mJwP9Oxy8nB0tps9rXXYeiNeY OMCREBfYllgIpKzdDf4G4RzGUCLgKK+PIzX+DR37nzVd0ZSbpcND696RdSYu9wK5OQkF I0Sg== X-Gm-Message-State: AJaThX53daKFX0NYf9du8Ls2eranZoJ7+Gq6JKrDnGflnP4XKY5GVzh7 7UZBsKzOVSg4V9KY2SVizv6OF+KtAuOHjuBKFf1eAg== X-Google-Smtp-Source: ABhQp+QccZO6vu3Tl5MHjM7ak6/PvwReGJ1moQ0X0DPvM9L1L764bptPvejXlOwOrX8IfKOGGqraphqiZ6XS6eKPUzM= X-Received: by 10.107.52.134 with SMTP id b128mr7261724ioa.291.1509677168605; Thu, 02 Nov 2017 19:46:08 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 2 Nov 2017 19:46:07 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:a004:68c9:b567:b3a8] In-Reply-To: <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> From: Warner Losh Date: Thu, 2 Nov 2017 20:46:07 -0600 X-Google-Sender-Auth: 5wZ40yowwbjgdom3Qo4ypLN2NWU Message-ID: Subject: Re: Head build unsafe for /etc today To: Bryan Drewery Cc: Steve Kargl , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:46:09 -0000 On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery wrote: > > > > On Nov 2, 2017, at 19:23, Steve Kargl > wrote: > > > >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > >> > >> > >>>> On Nov 2, 2017, at 18:49, Steve Kargl edu> wrote: > >>>> > >>>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: > >>>> > >>>> On Nov 2, 2017, at 15:44, Mark Millard wrote: > >>>> > >>>>>> Author: bdrewery > >>>>>> Date: Thu Nov 2 22:23:00 2017 > >>>>>> New Revision: 325347 > >>>>>> URL: > >>>>>> https://svnweb.freebsd.org/changeset/base/325347 > >>>>>> > >>>>>> > >>>>>> Log: > >>>>>> Something is very wrong > >>>> > >>>> > >>>> Unfortunately I only test with META_MODE these days which implies > -DNO_CLEAN. > >>> > >>> You're making changes to the build infrastructure and you're > >>> not properly testing it before committing? This is beyond > >>> pointyhat material. > >> > >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of > installworld and installkernel, several xdev and native-xtools, several > full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir > cleans, tested several targets together, ran various special case tests f= or > submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and > tested symlinked objdirs special, ran it through my work repro a few time= s, > did special testing in rescue/, and had a volunteer test release. In the > process I found a bmake bug, GPL_DTC build bug and several others I don= =E2=80=99t > recall from the bus. > >> > >> What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because I for= got it even > exists. I=E2=80=99ve wanted to remove it for a year. I also forgot to tes= t buildenv. > >> > > > > If you did all the above under META_MODE, then no you did not > > buildworld and buildkernel and all the other stuff you claim. > > Are you accusing me of lying? > > > > If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent > > in whatever jail you use, then you're not properly testing > > your changes to the build > > I did that probably 100 times. And that isn=E2=80=99t even =E2=80=9Cthe p= roper test=E2=80=9D. Both > clean and incremental are needed which I did. zfs snapshots help a lot > there. I just never ran =E2=80=9C_cleanobj=E2=80=9D which does a full tre= e walk of clean. > But I ran make clean in some subdirs many times. > > > infrastructure. As you have demonstrated, > > Makefile, Makefile.inc1, and the *.mk files are sufficiently > > complicated that proper testing > > > should be done, and proper > > testing means one doesn't takes shortcuts. > > I took 0 shortcuts. As I said I *forgot* that case, among hundreds of > cases. > You=E2=80=99re welcome to do this work if you want. I guarantee you would= not have > tested even half of what I tested. > > Hey can you fix universe to only build clang once please? I=E2=80=99ve be= en > working up to that but I think you=E2=80=99re best to do it. Given the hundreds of commits to the build system and its complexity, I'm in awe this doesn't happen more often. Heck, I've done an order of magnitude fewer commits to the build system and broken it more often than you have, and that's when it was a much simpler beast than it is today. Steve's just being overly grumpy imho. Accidents happen despite one's best efforts. This is -current after all... Warner From owner-freebsd-hackers@freebsd.org Fri Nov 3 02:47:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5211E69710 for ; Fri, 3 Nov 2017 02:47:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-136.reflexion.net [208.70.210.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFF9D73A5C for ; Fri, 3 Nov 2017 02:47:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30646 invoked from network); 3 Nov 2017 02:47:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 02:47:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 02 Nov 2017 22:47:23 -0400 (EDT) Received: (qmail 3212 invoked from network); 3 Nov 2017 02:47:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 02:47:22 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0BD49EC86EF; Thu, 2 Nov 2017 19:47:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools From: Mark Millard In-Reply-To: Date: Thu, 2 Nov 2017 19:47:20 -0700 Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:47:31 -0000 [Top post as it does not flow with the prior material.] Back-to-back repeats of the same buildworld buildkernel command are rebuilding lots of obj-lib32 *.o files and the like each time under WITH_META_MODE=3Dyes for -r325351. Script started on Thu Nov 2 18:34:57 2017 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel vs. Script started on Thu Nov 2 18:34:57 2017 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel # svnlite status -u -r325351 /usr/src | sort * 320623 = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M 325351 = /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M 325351 /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M 325351 /usr/src/crypto/openssl/crypto/armcap.c M 325351 /usr/src/lib/libkvm/kvm_powerpc.c M 325351 /usr/src/lib/libkvm/kvm_private.c M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c M 325351 /usr/src/sys/arm64/arm64/identcpu.c M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi M 325351 /usr/src/sys/boot/ofw/Makefile.inc M 325351 /usr/src/sys/boot/powerpc/Makefile.inc M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile M 325351 /usr/src/sys/boot/uboot/Makefile.inc M 325351 /usr/src/sys/conf/kmod.mk M 325351 /usr/src/sys/conf/ldscript.powerpc M 325351 /usr/src/sys/kern/subr_pcpu.c M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c M 325351 /usr/src/sys/powerpc/powerpc/trap.c -------------------------------------------------------------- >>> stage 5.1: building lib32 shim libraries -------------------------------------------------------------- . . . --- obj --- --- lib/libgcc_eh__PL --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.o --- gnu/lib/libssp/libssp_nonshared__PL --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/libssp/libssp_nonshared/_libinstall --- lib/libcompiler_rt__PL --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libcompiler_rt/_libinstall Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libcompiler_rt/_installlinks --- _installlinks --- /usr/lib32/libgcc.a -> libcompiler_rt.a --- lib/libgcc_eh__PL --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libgcc_eh.a --- libgcc_eh.a --- building static gcc_eh library Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/_libinstall --- gnu/lib/csu__L --- --- lib/csu__L --- --- lib/libcompiler_rt__L --- --- lib/libc__L --- --- gnu/lib/csu__L --- =3D=3D=3D> gnu/lib/csu (obj,all,install) --- lib/csu__L --- =3D=3D=3D> lib/csu (obj,all,install) --- lib/libcompiler_rt__L --- =3D=3D=3D> lib/libcompiler_rt (obj,all,install) --- lib/libc__L --- =3D=3D=3D> lib/libc (obj,all,install) --- lib/csu__L --- --- obj_subdir_lib/csu/i386 --- =3D=3D=3D> lib/csu/i386 (obj) --- gnu/lib/csu__L --- --- obj --- --- lib/csu__L --- --- obj --- --- all_subdir_lib/csu/i386 --- =3D=3D=3D> lib/csu/i386 (all) --- lib/libcompiler_rt__L --- --- obj --- --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbegin.o --- lib/csu__L --- --- realinstall_subdir_lib/csu/i386 --- =3D=3D=3D> lib/csu/i386 (install) Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/csu/i386/_FILESINS --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtend.o --- lib/libc_nonshared__L --- =3D=3D=3D> lib/libc_nonshared (obj,all,install) --- obj --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/__iconv.o --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbeginT.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/__iconv_free_list.o --- lib/libcompiler_rt__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libcompiler_rt/_libinstall Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libcompiler_rt/_installlinks --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/__iconv_get_list.o --- lib/libcompiler_rt__L --- --- _installlinks --- /usr/lib32/libgcc.a -> libcompiler_rt.a --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbeginS.o --- lib/libcompiler_rt__L --- /usr/lib32/libgcc_p.a -> libcompiler_rt_p.a --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtendS.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv_canonicalize.o --- lib/libgcc_eh__L --- =3D=3D=3D> lib/libgcc_eh (obj,all,install) --- lib/libc__L --- --- obj --- --- lib/libgcc_eh__L --- --- obj --- --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv_close.o --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtend.o --- lib/libgcc_eh__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv_open.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv_open_into.o --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbeginT.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconv_set_relocation_prefix.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconvctl.o --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbeginS.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/iconvlist.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/libc_nonshared.a --- libc_nonshared.a --- building static c_nonshared library --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtendS.o --- lib/libc_nonshared__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc_nonshared/_libinstall --- lib/libgcc_eh__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.po --- gnu/lib/csu__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/crtbegin.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/csu/_FILESINS --- lib/libgcc_eh__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libgcc_eh.a --- libgcc_eh.a --- building static gcc_eh library --- lib/libc__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/machdep_ldisx.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_close.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_delete.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_get.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_open.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_put.o --- lib/libgcc_eh__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libgcc_eh_p.a --- libgcc_eh_p.a --- building profiled gcc_eh library --- lib/libc__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/bt_seq.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/db.o --- lib/libgcc_eh__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/_libinstall --- lib/libc__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/hash.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/hash_bigkey.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/hash_page.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/ndbm.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/mpool.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_close.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_delete.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_get.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_open.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_put.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_search.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/rec_seq.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/getwd.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/killpg.o Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libc/sigcompat.o . . . --- lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/librt/librt.so.1.debug Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/librt/librt.so.1 --- all_subdir_lib/libpcap --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libpcap/etherent.po --- secure/lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /secure/lib/libssl/ssl_sess.pico --- lib__L --- --- all_subdir_lib/librtld_db --- =3D=3D=3D> lib/librtld_db (all) Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/librtld_db/rtld_db.o --- kerberos5/lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /kerberos5/lib/libgssapi_ntlm/external.o --- lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/librtld_db/rtld_db.po --- kerberos5/lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /kerberos5/lib/libgssapi_ntlm/import_name.o --- secure/lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /secure/lib/libssl/ssl_stat.pico --- lib__L --- Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/librtld_db/rtld_db.pico . . . And so on. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Nov-2, at 5:30 PM, Bryan Drewery wrote: On 11/2/17 3:44 PM, Mark Millard wrote: >> Author: bdrewery >> Date: Thu Nov 2 22:23:00 2017 >> New Revision: 325347 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/325347 >>=20 >>=20 >> Log: >> Something is very wrong >>=20 >> Modified: >> head/Makefile >>=20 >> Modified: head/Makefile >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >> @@ -1,3 +1,4 @@ >> +.error Bad revision, please wait for a fix in head >> # >> # $FreeBSD$ >> # >=20 > I just happened to have started a cross build before > this showed up based on -r325332 . It got: >=20 > --- clang-tblgen.full --- > c++: error: no such file or directory: = '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/= clang/libllvmminimal/libllvmminimal.a' > *** [clang-tblgen.full] Error code 1 Someone else reported this one as well but I have not been able to reproduce it yet. I've tweaked the commit causing it though, r325329. Fixed in r325350. >=20 > But find shows: >=20 > # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name = "libllvmminimal*" -print | more > = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal > = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a > = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta >=20 > Comparing side-by-side shows obj-cross-tools vs. > obj-bootstrap-tools : >=20 > = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a > = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:06:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA44FE69C9E; Fri, 3 Nov 2017 03:06:07 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72735745F5; Fri, 3 Nov 2017 03:06:07 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 93A0E16903; Fri, 3 Nov 2017 03:06:06 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id CFB548F4F; Fri, 3 Nov 2017 03:06:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id LAEQHjH4CdO7; Fri, 3 Nov 2017 03:06:00 +0000 (UTC) Subject: Re: Head build unsafe for /etc today DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 386F68F4A Cc: Warner Losh , Steve Kargl , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Thu, 2 Nov 2017 20:05:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EIO8tKeXplnkUnsgPme1tH9JiIfD106Ft" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:06:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EIO8tKeXplnkUnsgPme1tH9JiIfD106Ft Content-Type: multipart/mixed; boundary="l9s2H3bNWWDRX0hDhTuGWTniSVsePRB8K"; protected-headers="v1" From: Bryan Drewery Cc: Warner Losh , Steve Kargl , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Message-ID: Subject: Re: Head build unsafe for /etc today References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> In-Reply-To: --l9s2H3bNWWDRX0hDhTuGWTniSVsePRB8K Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/2017 7:46 PM, Warner Losh wrote: >=20 >=20 > On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery > wrote: >=20 >=20 >=20 > > On Nov 2, 2017, at 19:23, Steve Kargl > wrote: > > > >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > >> > >> > >>>> On Nov 2, 2017, at 18:49, Steve Kargl > wrote: > >>>> > >>>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:= > >>>> > >>>> On Nov 2, 2017, at 15:44, Mark Millard > wrote: > >>>> > >>>>>> Author: bdrewery > >>>>>> Date: Thu Nov=C2=A0 2 22:23:00 2017 > >>>>>> New Revision: 325347 > >>>>>> URL: > >>>>>> https://svnweb.freebsd.org/changeset/base/325347 > > >>>>>> > >>>>>> > >>>>>> Log: > >>>>>> Something is very wrong > >>>> > >>>> > >>>> Unfortunately I only test with META_MODE these days which impl= ies -DNO_CLEAN. > >>> > >>> You're making changes to the build infrastructure and you're > >>> not properly testing it before committing?=C2=A0 This is beyond= > >>> pointyhat material. > >> > >> I ran 2 universes, dozens of buildworlds and buildkernels, dozen= s of installworld and installkernel, several xdev and native-xtools, seve= ral full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subd= ir cleans, tested several targets together, ran various special case test= s for submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handl= ed and tested symlinked objdirs special, ran it through my work repro a f= ew times, did special testing in rescue/, and had a volunteer test releas= e.=C2=A0 In the process=C2=A0 I found a bmake bug, GPL_DTC build bug and = several others I don=E2=80=99t recall from the bus. > >> > >> What I missed was the =E2=80=9Cclean=E2=80=9D buildworld because= I forgot it even exists. I=E2=80=99ve wanted to remove it for a year. I = also forgot to test buildenv. > >> > > > > If you did all the above under META_MODE, then no you did not > > buildworld and buildkernel and all the other stuff you claim. >=20 > Are you accusing me of lying? >=20 >=20 > > If your first step isn't=C2=A0 'cd /usr/obj ; rm -rf *' or equiva= lent > > in whatever jail you use, then you're not properly testing > > your changes to the build >=20 > I did that probably 100 times. And that isn=E2=80=99t even =E2=80=9C= the proper > test=E2=80=9D. Both clean and incremental are needed which I did. z= fs > snapshots help a lot there. I just never ran =E2=80=9C_cleanobj=E2=80= =9D which does > a full tree walk of clean. But I ran make clean in some subdirs man= y > times. >=20 > > infrastructure.=C2=A0 As you have demonstrated, > > Makefile, Makefile.inc1, and the *.mk files are sufficiently > > complicated that proper testing >=20 > > should be done, and proper > > testing means one doesn't takes shortcuts. >=20 > I took 0 shortcuts. As I said I *forgot* that case, among hundreds > of cases. > You=E2=80=99re welcome to do this work if you want. I guarantee you= would > not have tested even half of what I tested. >=20 > Hey can you fix universe to only build clang once please? I=E2=80=99= ve been > working up to that but I think you=E2=80=99re best to do it. >=20 >=20 > Given the hundreds of commits to the build system and its complexity, > I'm in awe this doesn't happen more often. Heck, I've done an order of > magnitude fewer commits to the build system and broken it more often > than you have, and that's when it was a much simpler beast than it is t= oday. >=20 > Steve's just being overly grumpy imho.=C2=A0 Accidents happen despite o= ne's > best efforts. This is -current after all... Sorry I became grumpy too... I am truly sorry for anyone bit by this. I understand being angry about it. I too was bitten by it and scrambled to get a fix in on a random system I had up without much information on what the root cause was. At first I thought it was the last minute bmake update which came in after my change since I had no seen anything like this in my testing. The commit which caused the problem was reviewed, but the bug was dormant in unchanged code. The bug is fixed now, but I am going to keep the AUTO_OBJ feature off for a few days until I add a few more seatbelts to prevent this again. --=20 Regards, Bryan Drewery --l9s2H3bNWWDRX0hDhTuGWTniSVsePRB8K-- --EIO8tKeXplnkUnsgPme1tH9JiIfD106Ft 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 iQEcBAEBAgAGBQJZ+90XAAoJEDXXcbtuRpfPvYEH/j14yF/c6c78Y3yOsTCZmFzA oPcaxHOYpI/L2kaI+sxlVgwob8xJusj1nvoWDfiC9Ol2vJcaIFHmuVQfZqqy7KV8 aI+nDafC1TWlYIGV8lUaHyGGpsYf3qxhi7c/UHz5yyFeYOcJrr7BZdr36NyuVqn7 2Mhasb9YWADjLV6QzONN50RKbbX3y/HpQ008zPbGG6yLfA3lpwsna36LZ5GFN20K thkgC0zmKw7LktLpPpHl3+dWssnduZEGNLgBWjwEcA6zS5KehhfQJwiXMvUcGFpE G9ewiagL8AXaoy62qTtMhBm+dnos26X4RFlgOuUO+uxUeEy1rwGrnNTchOa79q0= =uDrt -----END PGP SIGNATURE----- --EIO8tKeXplnkUnsgPme1tH9JiIfD106Ft-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:08:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98E93E69EE0; Fri, 3 Nov 2017 03:08:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6297D7492D; Fri, 3 Nov 2017 03:08:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7DDCE16ABC; Fri, 3 Nov 2017 03:08:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id BB2828F81; Fri, 3 Nov 2017 03:08:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 4BBJlM-hkzje; Fri, 3 Nov 2017 03:08:25 +0000 (UTC) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 219958F7C To: Mark Millard Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> Date: Thu, 2 Nov 2017 20:08:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XgGBCRktoxhtFs1lO0cMHd5qC9mSqv3pt" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:08:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XgGBCRktoxhtFs1lO0cMHd5qC9mSqv3pt Content-Type: multipart/mixed; boundary="Bjs6jpHlaHUJ5CoBB99C3xrRC8e21udKd"; protected-headers="v1" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Message-ID: <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> In-Reply-To: --Bjs6jpHlaHUJ5CoBB99C3xrRC8e21udKd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/2017 7:47 PM, Mark Millard wrote: > [Top post as it does not flow with the prior material.] >=20 > Back-to-back repeats of the same buildworld buildkernel > command are rebuilding lots of obj-lib32 *.o files and > the like each time under WITH_META_MODE=3Dyes for -r325351. >=20 I think it is expected since I had to change the objdirs for build/cross tools again to fix your report. I am very confused how I never hit the issue you and Matt ran into. I had this commit sitting in my test branch for days. It may just be due to SYSTEM_COMPILER getting triggered. There's so many combinations of options in the early build that it's impossible to test all of them. Anyway if it continues to happen please also pass -dM to your make as it will tell us why it is rebuilding. > Script started on Thu Nov 2 18:34:57 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/n= ull SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host WITH= _META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 make= -j4 buildworld buildkernel >=20 > vs. >=20 > Script started on Thu Nov 2 18:34:57 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/n= ull SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host WITH= _META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 make= -j4 buildworld buildkernel >=20 >=20 > # svnlite status -u -r325351 /usr/src | sort > * 320623 /usr/src/contrib/jemalloc/include/jemalloc/interna= l/tsd.h > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M 325351 /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameL= owering.cpp > M 325351 /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp= > M 325351 /usr/src/crypto/openssl/crypto/armcap.c > M 325351 /usr/src/lib/libkvm/kvm_powerpc.c > M 325351 /usr/src/lib/libkvm/kvm_private.c > M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c > M 325351 /usr/src/sys/arm64/arm64/identcpu.c > M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > M 325351 /usr/src/sys/boot/ofw/Makefile.inc > M 325351 /usr/src/sys/boot/powerpc/Makefile.inc > M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile > M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile > M 325351 /usr/src/sys/boot/uboot/Makefile.inc > M 325351 /usr/src/sys/conf/kmod.mk > M 325351 /usr/src/sys/conf/ldscript.powerpc > M 325351 /usr/src/sys/kern/subr_pcpu.c > M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c > M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c > M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c > M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c > M 325351 /usr/src/sys/powerpc/powerpc/trap.c >=20 >=20 > -------------------------------------------------------------- >>>> stage 5.1: building lib32 shim libraries > -------------------------------------------------------------- > . . . > --- obj --- > --- lib/libgcc_eh__PL --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libunwind.o > --- gnu/lib/libssp/libssp_nonshared__PL --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall > --- lib/libcompiler_rt__PL --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libcompiler_rt/_libinstall > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libcompiler_rt/_installlinks > --- _installlinks --- > /usr/lib32/libgcc.a -> libcompiler_rt.a > --- lib/libgcc_eh__PL --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libgcc_eh.a > --- libgcc_eh.a --- > building static gcc_eh library > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/_libinstall > --- gnu/lib/csu__L --- > --- lib/csu__L --- > --- lib/libcompiler_rt__L --- > --- lib/libc__L --- > --- gnu/lib/csu__L --- > =3D=3D=3D> gnu/lib/csu (obj,all,install) > --- lib/csu__L --- > =3D=3D=3D> lib/csu (obj,all,install) > --- lib/libcompiler_rt__L --- > =3D=3D=3D> lib/libcompiler_rt (obj,all,install) > --- lib/libc__L --- > =3D=3D=3D> lib/libc (obj,all,install) > --- lib/csu__L --- > --- obj_subdir_lib/csu/i386 --- > =3D=3D=3D> lib/csu/i386 (obj) > --- gnu/lib/csu__L --- > --- obj --- > --- lib/csu__L --- > --- obj --- > --- all_subdir_lib/csu/i386 --- > =3D=3D=3D> lib/csu/i386 (all) > --- lib/libcompiler_rt__L --- > --- obj --- > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbegin.o > --- lib/csu__L --- > --- realinstall_subdir_lib/csu/i386 --- > =3D=3D=3D> lib/csu/i386 (install) > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/csu/i386/_FILESINS > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtend.o > --- lib/libc_nonshared__L --- > =3D=3D=3D> lib/libc_nonshared (obj,all,install) > --- obj --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/__iconv.o > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbeginT.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/__iconv_free_list.o > --- lib/libcompiler_rt__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libcompiler_rt/_libinstall > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libcompiler_rt/_installlinks > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/__iconv_get_list.o > --- lib/libcompiler_rt__L --- > --- _installlinks --- > /usr/lib32/libgcc.a -> libcompiler_rt.a > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbeginS.o > --- lib/libcompiler_rt__L --- > /usr/lib32/libgcc_p.a -> libcompiler_rt_p.a > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtendS.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv_canonicalize.o > --- lib/libgcc_eh__L --- > =3D=3D=3D> lib/libgcc_eh (obj,all,install) > --- lib/libc__L --- > --- obj --- > --- lib/libgcc_eh__L --- > --- obj --- > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv_close.o > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtend.o > --- lib/libgcc_eh__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libunwind.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv_open.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv_open_into.o > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbeginT.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconv_set_relocation_prefix.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconvctl.o > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbeginS.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/iconvlist.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/libc_nonshared.a > --- libc_nonshared.a --- > building static c_nonshared library > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtendS.o > --- lib/libc_nonshared__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc_nonshared/_libinstall > --- lib/libgcc_eh__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libunwind.po > --- gnu/lib/csu__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/crtbegin.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/gnu/lib/csu/_FILESINS > --- lib/libgcc_eh__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libgcc_eh.a > --- libgcc_eh.a --- > building static gcc_eh library > --- lib/libc__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/machdep_ldisx.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_close.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_delete.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_get.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_open.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_put.o > --- lib/libgcc_eh__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/libgcc_eh_p.a > --- libgcc_eh_p.a --- > building profiled gcc_eh library > --- lib/libc__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/bt_seq.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/db.o > --- lib/libgcc_eh__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libgcc_eh/_libinstall > --- lib/libc__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/hash.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/hash_bigkey.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/hash_page.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/ndbm.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/mpool.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_close.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_delete.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_get.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_open.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_put.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_search.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/rec_seq.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/getwd.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/killpg.o > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libc/sigcompat.o > . . . > --- lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/librt/librt.so.1.debug > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/librt/librt.so.1 > --- all_subdir_lib/libpcap --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/libpcap/etherent.po > --- secure/lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/secure/lib/libssl/ssl_sess.pico > --- lib__L --- > --- all_subdir_lib/librtld_db --- > =3D=3D=3D> lib/librtld_db (all) > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/librtld_db/rtld_db.o > --- kerberos5/lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/kerberos5/lib/libgssapi_ntlm/external.o > --- lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/librtld_db/rtld_db.po > --- kerberos5/lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/kerberos5/lib/libgssapi_ntlm/import_name.o > --- secure/lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/secure/lib/libssl/ssl_stat.pico > --- lib__L --- > Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32= /amd64.amd64/lib/librtld_db/rtld_db.pico > . . . >=20 > And so on. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Nov-2, at 5:30 PM, Bryan Drewery wrote: >=20 > On 11/2/17 3:44 PM, Mark Millard wrote: >>> Author: bdrewery >>> Date: Thu Nov 2 22:23:00 2017 >>> New Revision: 325347 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/325347 >>> >>> >>> Log: >>> Something is very wrong >>> >>> Modified: >>> head/Makefile >>> >>> Modified: head/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >>> @@ -1,3 +1,4 @@ >>> +.error Bad revision, please wait for a fix in head >>> # >>> # $FreeBSD$ >>> # >> >> I just happened to have started a cross build before >> this showed up based on -r325332 . It got: >> >> --- clang-tblgen.full --- >> c++: error: no such file or directory: '/usr/obj/bpim3_clang/arm.armv7= /usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmmi= nimal.a' >> *** [clang-tblgen.full] Error code 1 >=20 > Someone else reported this one as well but I have not been able to > reproduce it yet. >=20 > I've tweaked the commit causing it though, r325329. Fixed in r325350. >=20 >> >> But find shows: >> >> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libllvm= minimal*" -print | more >> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-too= ls/lib/clang/libllvmminimal >> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-too= ls/lib/clang/libllvmminimal/libllvmminimal.a >> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-too= ls/lib/clang/libllvmminimal/libllvmminimal.a.meta >> >> Comparing side-by-side shows obj-cross-tools vs. >> obj-bootstrap-tools : >> >> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-too= ls/lib/clang/libllvmminimal/libllvmminimal.a >> >> >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >> >=20 >=20 --=20 Regards, Bryan Drewery --Bjs6jpHlaHUJ5CoBB99C3xrRC8e21udKd-- --XgGBCRktoxhtFs1lO0cMHd5qC9mSqv3pt 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 iQEcBAEBAgAGBQJZ+92pAAoJEDXXcbtuRpfPJWoH/AxHxj4nGc5RxlFzYh9Q9e4C rhAq2ljzlrfHIs9m6KJFQL6iCRn3TIQJI50iIGKNhnH15RNEPUZ+xVv+ObVc0SPl rD1rWT2fmN0hFAv6gf4Dcq30ljZ2hwW5UgLdcONzTNbX0QGKQjSek5Espq+uaQVS 2+pWWyJoeoMUYQvdR+/cXCqood8+R3QrVsxbXR9FqS5+yN3lazDLc0i+LAbEnR8R mCBZ3dTcMAIWQWO5Ub7aR3QHxvmX917HzO17lcXn+6IVb18jRhzfmELNcosvyxjZ GLX0EQe4vPZDANXVCudeMBvwMdId6NiLFzexJUAQC7+m89ZBVwDtk/yrwzYAZl4= =INgD -----END PGP SIGNATURE----- --XgGBCRktoxhtFs1lO0cMHd5qC9mSqv3pt-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:16:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57565E6A39B for ; Fri, 3 Nov 2017 03:16:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-147.reflexion.net [208.70.210.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14AAF750B7 for ; Fri, 3 Nov 2017 03:16:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22602 invoked from network); 3 Nov 2017 03:16:33 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 03:16:33 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 02 Nov 2017 23:16:33 -0400 (EDT) Received: (qmail 27669 invoked from network); 3 Nov 2017 03:16:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 03:16:32 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2C8DAEC9500; Thu, 2 Nov 2017 20:16:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools From: Mark Millard In-Reply-To: <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> Date: Thu, 2 Nov 2017 20:16:31 -0700 Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:16:40 -0000 On 2017-Nov-2, at 8:08 PM, Bryan Drewery wrote: > On 11/2/2017 7:47 PM, Mark Millard wrote: >> [Top post as it does not flow with the prior material.] >>=20 >> Back-to-back repeats of the same buildworld buildkernel >> command are rebuilding lots of obj-lib32 *.o files and >> the like each time under WITH_META_MODE=3Dyes for -r325351. >>=20 >=20 > I think it is expected since I had to change the objdirs for = build/cross > tools again to fix your report. FYI: that was after several prior builds with -r325351. It is not just a first-repeat example. > I am very confused how I never hit the issue you and Matt ran into. I > had this commit sitting in my test branch for days. It may just be = due > to SYSTEM_COMPILER getting triggered. There's so many combinations of > options in the early build that it's impossible to test all of them. I had WITH_META_MODE=3Dyes as I normally do but had done the rm -fr of the tree content as well (because of directory tree structure mismatches that would be in the new build). > Anyway if it continues to happen please also pass -dM to your make as = it > will tell us why it is rebuilding. I'm about to try that. >> Script started on Thu Nov 2 18:34:57 2017 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>=20 >> vs. >>=20 >> Script started on Thu Nov 2 18:34:57 2017 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>=20 >>=20 >> # svnlite status -u -r325351 /usr/src | sort >> * 320623 = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h >> ? /usr/src/sys/amd64/conf/GENERIC-DBG >> ? /usr/src/sys/amd64/conf/GENERIC-NODBG >> ? /usr/src/sys/arm/conf/GENERIC-DBG >> ? /usr/src/sys/arm/conf/GENERIC-NODBG >> ? /usr/src/sys/arm64/conf/GENERIC-DBG >> ? /usr/src/sys/arm64/conf/GENERIC-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG >> M 325351 = /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp >> M 325351 = /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp >> M 325351 /usr/src/crypto/openssl/crypto/armcap.c >> M 325351 /usr/src/lib/libkvm/kvm_powerpc.c >> M 325351 /usr/src/lib/libkvm/kvm_private.c >> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c >> M 325351 /usr/src/sys/arm64/arm64/identcpu.c >> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >> M 325351 /usr/src/sys/boot/ofw/Makefile.inc >> M 325351 /usr/src/sys/boot/powerpc/Makefile.inc >> M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile >> M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile >> M 325351 /usr/src/sys/boot/uboot/Makefile.inc >> M 325351 /usr/src/sys/conf/kmod.mk >> M 325351 /usr/src/sys/conf/ldscript.powerpc >> M 325351 /usr/src/sys/kern/subr_pcpu.c >> M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c >> M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c >> M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c >> M 325351 /usr/src/sys/powerpc/powerpc/trap.c >>=20 >>=20 >> -------------------------------------------------------------- >>>>> stage 5.1: building lib32 shim libraries >> -------------------------------------------------------------- >> . . . >> --- obj --- >> --- lib/libgcc_eh__PL --- >> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.o >> --- gnu/lib/libssp/libssp_nonshared__PL --- >> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/libssp/libssp_nonshared/_libinstall >> . . . >> . . . >>=20 >> And so on. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Nov-2, at 5:30 PM, Bryan Drewery wrote: >=20 > On 11/2/17 3:44 PM, Mark Millard wrote: >>> Author: bdrewery >>> Date: Thu Nov 2 22:23:00 2017 >>> New Revision: 325347 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/325347 >>>=20 >>>=20 >>> Log: >>> Something is very wrong >>>=20 >>> Modified: >>> head/Makefile >>>=20 >>> Modified: head/Makefile >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >>> @@ -1,3 +1,4 @@ >>> +.error Bad revision, please wait for a fix in head >>> # >>> # $FreeBSD$ >>> # >>=20 >> I just happened to have started a cross build before >> this showed up based on -r325332 . It got: >>=20 >> --- clang-tblgen.full --- >> c++: error: no such file or directory: = '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/= clang/libllvmminimal/libllvmminimal.a' >> *** [clang-tblgen.full] Error code 1 >=20 > Someone else reported this one as well but I have not been able to > reproduce it yet. >=20 > I've tweaked the commit causing it though, r325329. Fixed in r325350. >=20 >>=20 >> But find shows: >>=20 >> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name = "libllvmminimal*" -print | more >> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal >> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta >>=20 >> Comparing side-by-side shows obj-cross-tools vs. >> obj-bootstrap-tools : >>=20 >> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a >> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 >=20 --=20 Regards, Bryan Drewery From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:38:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1816E6AB0C for ; Fri, 3 Nov 2017 03:38:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61D8175B56 for ; Fri, 3 Nov 2017 03:38:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21209 invoked from network); 3 Nov 2017 03:31:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 03:31:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 02 Nov 2017 23:31:33 -0400 (EDT) Received: (qmail 7625 invoked from network); 3 Nov 2017 03:31:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 03:31:33 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id DA37CEC86EF; Thu, 2 Nov 2017 20:31:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools From: Mark Millard In-Reply-To: <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> Date: Thu, 2 Nov 2017 20:31:32 -0700 Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:38:20 -0000 [The rebuilding is not your problem. . . Its a file system time problem.] On 2017-Nov-2, at 8:16 PM, Mark Millard wrote: > On 2017-Nov-2, at 8:08 PM, Bryan Drewery wrote: >=20 >> On 11/2/2017 7:47 PM, Mark Millard wrote: >>> [Top post as it does not flow with the prior material.] >>>=20 >>> Back-to-back repeats of the same buildworld buildkernel >>> command are rebuilding lots of obj-lib32 *.o files and >>> the like each time under WITH_META_MODE=3Dyes for -r325351. >>>=20 >>=20 >> I think it is expected since I had to change the objdirs for = build/cross >> tools again to fix your report. >=20 > FYI: that was after several prior builds with -r325351. It is > not just a first-repeat example. >=20 >> I am very confused how I never hit the issue you and Matt ran into. I >> had this commit sitting in my test branch for days. It may just be = due >> to SYSTEM_COMPILER getting triggered. There's so many combinations = of >> options in the early build that it's impossible to test all of them. >=20 > I had WITH_META_MODE=3Dyes as I normally do but had done > the rm -fr of the tree content as well (because of > directory tree structure mismatches that would be in > the new build). >=20 >> Anyway if it continues to happen please also pass -dM to your make as = it >> will tell us why it is rebuilding. >=20 > I'm about to try that. It reported a more up-to-date file. But looking the timestamp was in the future (tomorrow, almost 24 hours away): # ls -lT = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/inc= lude/runetype.h -rwxr-xr-x 1 root wheel 3906 Nov 3 20:13:14 2017 = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/inc= lude/runetype.h Apparently one or more of the times when I booted the virtual machine recently it ended up with a bad time and part of at least /usr/include has the problem with timestamps: # ls -lT /usr/include/runetype.h -r--r--r-- 1 root wheel 3906 Nov 3 22:48:30 2017 = /usr/include/runetype.h (The time for the active boot is fine.) Sorry for the noise. >>> Script started on Thu Nov 2 18:34:57 2017 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>>=20 >>> vs. >>>=20 >>> Script started on Thu Nov 2 18:34:57 2017 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>>=20 >>>=20 >>> # svnlite status -u -r325351 /usr/src | sort >>> * 320623 = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h >>> ? /usr/src/sys/amd64/conf/GENERIC-DBG >>> ? /usr/src/sys/amd64/conf/GENERIC-NODBG >>> ? /usr/src/sys/arm/conf/GENERIC-DBG >>> ? /usr/src/sys/arm/conf/GENERIC-NODBG >>> ? /usr/src/sys/arm64/conf/GENERIC-DBG >>> ? /usr/src/sys/arm64/conf/GENERIC-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG >>> M 325351 = /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp >>> M 325351 = /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp >>> M 325351 /usr/src/crypto/openssl/crypto/armcap.c >>> M 325351 /usr/src/lib/libkvm/kvm_powerpc.c >>> M 325351 /usr/src/lib/libkvm/kvm_private.c >>> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c >>> M 325351 /usr/src/sys/arm64/arm64/identcpu.c >>> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >>> M 325351 /usr/src/sys/boot/ofw/Makefile.inc >>> M 325351 /usr/src/sys/boot/powerpc/Makefile.inc >>> M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile >>> M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile >>> M 325351 /usr/src/sys/boot/uboot/Makefile.inc >>> M 325351 /usr/src/sys/conf/kmod.mk >>> M 325351 /usr/src/sys/conf/ldscript.powerpc >>> M 325351 /usr/src/sys/kern/subr_pcpu.c >>> M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c >>> M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c >>> M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c >>> M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c >>> M 325351 /usr/src/sys/powerpc/powerpc/trap.c >>>=20 >>>=20 >>> -------------------------------------------------------------- >>>>>> stage 5.1: building lib32 shim libraries >>> -------------------------------------------------------------- >>> . . . >>> --- obj --- >>> --- lib/libgcc_eh__PL --- >>> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.o >>> --- gnu/lib/libssp/libssp_nonshared__PL --- >>> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/libssp/libssp_nonshared/_libinstall >>> . . . >>> . . . >>>=20 >>> And so on. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2017-Nov-2, at 5:30 PM, Bryan Drewery = wrote: >>=20 >> On 11/2/17 3:44 PM, Mark Millard wrote: >>>> Author: bdrewery >>>> Date: Thu Nov 2 22:23:00 2017 >>>> New Revision: 325347 >>>> URL:=20 >>>> https://svnweb.freebsd.org/changeset/base/325347 >>>>=20 >>>>=20 >>>> Log: >>>> Something is very wrong >>>>=20 >>>> Modified: >>>> head/Makefile >>>>=20 >>>> Modified: head/Makefile >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >>>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >>>> @@ -1,3 +1,4 @@ >>>> +.error Bad revision, please wait for a fix in head >>>> # >>>> # $FreeBSD$ >>>> # >>>=20 >>> I just happened to have started a cross build before >>> this showed up based on -r325332 . It got: >>>=20 >>> --- clang-tblgen.full --- >>> c++: error: no such file or directory: = '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/= clang/libllvmminimal/libllvmminimal.a' >>> *** [clang-tblgen.full] Error code 1 >>=20 >> Someone else reported this one as well but I have not been able to >> reproduce it yet. >>=20 >> I've tweaked the commit causing it though, r325329. Fixed in = r325350. >>=20 >>>=20 >>> But find shows: >>>=20 >>> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name = "libllvmminimal*" -print | more >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta >>>=20 >>> Comparing side-by-side shows obj-cross-tools vs. >>> obj-bootstrap-tools : >>>=20 >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>=20 >>=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:50:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3A1BE6AEE4; Fri, 3 Nov 2017 03:50:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B489F762AF; Fri, 3 Nov 2017 03:50:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vA33oA8A089328 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2017 20:50:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vA33oABE089327; Thu, 2 Nov 2017 20:50:10 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Nov 2017 20:50:10 -0700 From: Steve Kargl To: Bryan Drewery Cc: FreeBSD Toolchain , freebsd-hackers , FreeBSD Current Subject: Re: Head build unsafe for /etc today Message-ID: <20171103035010.GA89291@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:50:12 -0000 On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote: > > Are you accusing me of lying? > Nope. I'm stating the obvious. If you are using META_MODE and you do "make buildwould" that is equivalent to "make -DNO_CLEAN buildworld", which means you did not rebuild the *world*. When I see a commit message of the form (and I've haven't seen one like this in 25+ years of using FreeBSD (aka 386BSD+patchkit)) Author: bdrewery Date: Thu Nov 2 22:23:00 2017 New Revision: 325347 URL: https://svnweb.freebsd.org/changeset/base/325347 Log: Something is very wrong Modified: head/Makefile Modified: head/Makefile ============================================================================== --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) @@ -1,3 +1,4 @@ +.error Bad revision, please wait for a fix in head It suggests that whomever did the commit did not properly test the patch. The use of META_MODE (or any other shortcut) when testing simply isn't proper testing. -- Steve From owner-freebsd-hackers@freebsd.org Fri Nov 3 03:58:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D19E2E6B3B3 for ; Fri, 3 Nov 2017 03:58:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9398676959 for ; Fri, 3 Nov 2017 03:58:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id n137so3554247iod.6 for ; Thu, 02 Nov 2017 20:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ho6KNVCYaR2onhzgNBj6Gspyj9SajxCXRrNvfYw5ghA=; b=Z7NfGIvBbgK9Rl7JUyr8633NW9WMe1HNpd/s1rJTjhbinnYHHcermY6dGyRw6vvabV h9HaGNHGNPYlqn5gSuE7y5UzQ2x5YhwYHjL7wkpw2sFlIQpv8H4+3TABddQPJ4U9NVFx t1kQkgC9bOfS3e3J6njP3ytsKHwsU93PJoLCpLaV54GL/F4Tusm9fsoZdw/fwREijCH4 xCvnFwWlVhg+UcLk66u8JBS0M8lIgkWzOtIUFq/PqKK7xgvdCnnKopkzVtdIiW46YNj+ UHA7uOKRGX6A9wbPH6jP0sC+LWGJCM+kWwS9TuLW42PiksFyy3sJboMI3gGhskTbDX4J hYJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ho6KNVCYaR2onhzgNBj6Gspyj9SajxCXRrNvfYw5ghA=; b=nHW5gJLuuhHpl1WqJ0pBzeM9V68yfxKsWrgBGFSURBicqrhE1Sj5SFLOSw7W4P3Gus 8d2ArE3CHnUXgNz7yHO7eyv5fsQpOwDuEGmtkLwSmFFPoBrXwh7aDWGKqqI4BSB2bwqC XhawX/z8bD6PAQlp0Jjg6MHuv0qoGI6U9/NOVOF+M0469lsUnhgvjAolDVZDHgIfAIXA kUFXji86/G2H8ypvaXdLmYHKiNScPA/PZSdEQXqORh+CYibTxyue53/MCuMxKWMxoxcm uJ3N6ICGowy94cpx1rdL7pstDYG9/j3hy8sge4GH0pwqiH2nilFkW7syjupgNwK1nbxp +hiA== X-Gm-Message-State: AJaThX5FMyH39cXWRdlbXbSNBNcYi66gKOpcoMDXK55Bbqk//QkCpk34 0vWXQRPq35u7u4iMbROOCStDX2IuMVC0v9HI5A1MoA== X-Google-Smtp-Source: ABhQp+RczUBRhxSX+1DIVhZoOPltOWIIGqcWv5mcEc/1vUSnAFt7Y1B5hAF+Y5DZmD93crmplY6B8qzbDPBMwo7jFKs= X-Received: by 10.107.48.76 with SMTP id w73mr7499546iow.301.1509681510654; Thu, 02 Nov 2017 20:58:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 2 Nov 2017 20:58:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:a004:68c9:b567:b3a8] In-Reply-To: <20171103035010.GA89291@troutmask.apl.washington.edu> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> From: Warner Losh Date: Thu, 2 Nov 2017 21:58:29 -0600 X-Google-Sender-Auth: w6v6YhhJJ2tn4ba4Gq8Aya1J5WU Message-ID: Subject: Re: Head build unsafe for /etc today To: Steve Kargl Cc: Bryan Drewery , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:58:32 -0000 On Thu, Nov 2, 2017 at 9:50 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote: > > > > Are you accusing me of lying? > > > > Nope. I'm stating the obvious. If you are using > META_MODE and you do "make buildwould" that is > equivalent to "make -DNO_CLEAN buildworld", which > means you did not rebuild the *world*. > > When I see a commit message of the form (and I've > haven't seen one like this in 25+ years of using > FreeBSD (aka 386BSD+patchkit)) > > Author: bdrewery > Date: Thu Nov 2 22:23:00 2017 > New Revision: 325347 > URL: https://svnweb.freebsd.org/changeset/base/325347 > > Log: > Something is very wrong > > Modified: > head/Makefile > > Modified: head/Makefile > ============================================================ > ================== > --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) > +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) > @@ -1,3 +1,4 @@ > +.error Bad revision, please wait for a fix in head > > It suggests that whomever did the commit did not properly test > the patch. The use of META_MODE (or any other shortcut) when > testing simply isn't proper testing. FreeBSD has grown too big to test every possible thing before you commit. Lord knows the number of make universes I've done is maybe 1/100th the number of commits (or less) I've made. We all take short cuts, or fail to exhaustively test every single possible thing, or have some environmental contamination that normally isn't a problem but masks an issue, or forget to add a file / directory, or a hundred other things that can and do go wrong. It happens. It will happen again. I just hope to never again be the last person to break the tree before BSDcan again, but I live in fear that I'll miss something because I know I'm human. Personally, I think that this commit was the responsible thing to do: He'd just committed several changes. It wasn't clear which one needed to be backed out. While he tracked down the root cause, he put in counter measures to make sure that nobody else got bitten by the bug he himself encountered when he was further testing the system. He then resolved it by fixing the root cause, but I know that had he not been able to do so, he'd have backed things out. Part of being in this project is recognizing that and allowing the occasional oops to happen w/o making an unduly large case out of it... Warner Warner From owner-freebsd-hackers@freebsd.org Fri Nov 3 05:22:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7D1CE6C5D7 for ; Fri, 3 Nov 2017 05:22:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 703387C741 for ; Fri, 3 Nov 2017 05:22:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19347 invoked from network); 3 Nov 2017 05:22:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 05:22:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 03 Nov 2017 01:22:17 -0400 (EDT) Received: (qmail 25389 invoked from network); 3 Nov 2017 05:22:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 05:22:16 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ECA05EC8FCC; Thu, 2 Nov 2017 22:22:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Head build unsafe for /etc today From: Mark Millard In-Reply-To: <20171103035010.GA89291@troutmask.apl.washington.edu> Date: Thu, 2 Nov 2017 22:22:15 -0700 Cc: Bryan Drewery , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9BB08DDC-75A9-4115-936A-81E7319B166C@dsl-only.net> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 05:22:24 -0000 On 2017-Nov-2, at 8:50 PM, Steve Kargl = wrote: > On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote: >>=20 >> Are you accusing me of lying? >>=20 >=20 > Nope. I'm stating the obvious. If you are using > META_MODE and you do "make buildwould" that is=20 > equivalent to "make -DNO_CLEAN buildworld", which > means you did not rebuild the *world*.=20 Also from a prior message of this sequence: > If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent > in whatever jail you use, then you're not properly testing=20 > your changes to the build infrastructure. With or without META_MODE, a rm -fr /usr/obj/* before the build attempt forces a rebuild as far as I know. It may be more that cleaning was effectively not tested then rebuilding was not tested. But always doing rm -fr /usr/obj/* first establishes a very limited context for testing cleaning. WITH_META_MODE and WITHOUT_META_MODE still might not be strictly equivalent after the rm -fr /usr/obj/* for some other properties in such an "empty" context. So testing those combinations makes sense but would be insufficient. > When I see a commit message of the form (and I've > haven't seen one like this in 25+ years of using > FreeBSD (aka 386BSD+patchkit)) >=20 > Author: bdrewery > Date: Thu Nov 2 22:23:00 2017 > New Revision: 325347 > URL: https://svnweb.freebsd.org/changeset/base/325347 >=20 > Log: > Something is very wrong >=20 > Modified: > head/Makefile >=20 > Modified: head/Makefile > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) > +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) > @@ -1,3 +1,4 @@ > +.error Bad revision, please wait for a fix in head >=20 > It suggests that whomever did the commit did not properly test > the patch. The use of META_MODE (or any other shortcut) when > testing simply isn't proper testing. I think I understand the intended point but the actual wording for "the use of . . ." and "[i]f your first step isn't . . ." is wrong from what I can tell. The testing of WITH_META_MODE is a proper form of test but is not a sufficient category of test overall. But omitting all tests of WITH_META_MODE would be poor procedure in my view. Some testing needs to be done without rm -fr /usr/obj/* after a prior build as well. Some testing of WITH_META_MODE after a prior build needs to be done. Some testing of WITHOUT_META_MODE after a prior build needs to be done. And so on. At least that would be my view. Any and all mistakes checked-in are examples of insufficient testing --but always doing sufficient testing requires establishing a much simpler, more limited, context. To my knowledge FreeBSD is not trying to scale back like that. (It is not under the direction of an Edsger W. Dijkstra.) I do not know if something might be able to be done to make such a specific type of "clean test" mistake less likely to happen again. Could a test context be established where attempts to delete outside the build tree would be rejected, with notifications of the attempts? Could running such a test be automatic (part of something that is run systematically) and fast enough to not want to skip it? (Just being illustrative. The details involved are well outside my background knowledge. There may be nothing easy or reasonable.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Nov 3 08:59:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92E45E4C99D for ; Fri, 3 Nov 2017 08:59:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-126.reflexion.net [208.70.210.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 510C581405 for ; Fri, 3 Nov 2017 08:59:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16008 invoked from network); 3 Nov 2017 08:52:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 08:52:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 03 Nov 2017 04:52:34 -0400 (EDT) Received: (qmail 21525 invoked from network); 3 Nov 2017 08:52:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 08:52:34 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C958FEC86EF; Fri, 3 Nov 2017 01:52:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools From: Mark Millard In-Reply-To: <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> Date: Fri, 3 Nov 2017 01:52:33 -0700 Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 08:59:21 -0000 I did get another problem after buildworld, buildkernel, installkernel without future source code dates: the installworld got a "cc not found" for the amd64 native build based on -r325351 --that also appears to be set up to report: ERROR-tried-to-rebuild-during-make-install if cc had been found: .if defined(SRCTOP) # Prevent rebuilding during install to support read-only objdirs. .if ${.TARGETS:M*install*} =3D=3D ${.TARGETS} && empty(.MAKE.MODE:Mmeta) CFLAGS+=3D ERROR-tried-to-rebuild-during-make-install .endif=20 .endif=20 is involved in: Script started on Fri Nov 3 00:52:26 2017 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -dM -j4 installworld . . . --- realinstall_subdir_sys --- --- autoload.o --- --- realinstall_subdir_secure --- rm -f /usr/share/openssl/man/man3/SSL_set_generate_session_id.3 = /usr/share/openssl/man/man3/SSL_set_generate_session_id.3.gz; install = -l h /usr/share/openssl/man/man3/SSL_CTX_set_generate_session_id.3.gz = /usr/share/openssl/man/man3/SSL_set_generate_session_id.3.gz --- realinstall_subdir_sys --- cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 = -pipe -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -msoft-float = -fshort-wchar -mno-red-zone -mno-aes -DLOADER_UFS_SUPPORT = -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT = -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/boot/zfs = -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader = -I/usr/src/sys/boot/efi/loader/arch/amd64 = -I/usr/src/sys/boot/efi/include -I/usr/src/sys/boot/efi/include/amd64 = -I/usr/src/sys/contrib/dev/acpica/include -I/usr/src/sys = -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DSMBIOS_SERIAL_NUMBERS = -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot/ficl = -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FORTH = -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -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 = -Wno-unused-local-typedef -Wno-address-of-packed-member = -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -c = /usr/src/sys/boot/efi/loader/autoload.c -o autoload.o sh: cc: not found --- realinstall_subdir_secure --- rm -f /usr/share/openssl/man/man3/SSL_CTX_get_info_callback.3 = /usr/share/openssl/man/man3/SSL_CTX_get_info_callback.3.gz; install -l = h /usr/share/openssl/man/man3/SSL_CTX_set_info_callback.3.gz = /usr/share/openssl/man/man3/SSL_CTX_get_info_callback.3.gz --- realinstall_subdir_sys --- *** [autoload.o] Error code 127 make[7]: stopped in /usr/src/sys/boot/efi/loader 1 error make[7]: stopped in /usr/src/sys/boot/efi/loader *** [realinstall_subdir_sys/boot/efi/loader] Error code 2 Or without -j4: Script started on Fri Nov 3 01:38:54 2017 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -dM installworld . . . =3D=3D=3D> sys/boot/libsa32 (install) =3D=3D=3D> sys/boot/zfs (install) =3D=3D=3D> sys/boot/zfs32 (install) =3D=3D=3D> sys/boot/ficl32 (install) =3D=3D=3D> sys/boot/efi (install) =3D=3D=3D> sys/boot/efi/libefi (install) =3D=3D=3D> sys/boot/efi/loader (install) cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 = -pipe -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -msoft-float = -fshort-wchar -mno-red-zone -mno-aes -DLOADER_UFS_SUPPORT = -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT = -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/boot/zfs = -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader = -I/usr/src/sys/boot/efi/loader/arch/amd64 = -I/usr/src/sys/boot/efi/include -I/usr/src/sys/boot/efi/include/amd64 = -I/usr/src/sys/contrib/dev/acpica/include -I/usr/src/sys = -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DSMBIOS_SERIAL_NUMBERS = -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot/ficl = -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FORTH = -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -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 = -Wno-unused-local-typedef -Wno-address-of-packed-member = -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -c = /usr/src/sys/boot/efi/loader/autoload.c -o autoload.o /tmp/install.2mZZVhR0/sh: cc: not found *** Error code 127 Stop. make[7]: stopped in /usr/src/sys/boot/efi/loader *** Error code 1 I'll note: # ls -lT /usr/src/sys/boot/efi/loader/autoload.c -rw-r--r-- 1 root wheel 1522 Nov 3 02:27:17 2016 = /usr/src/sys/boot/efi/loader/autoload.c # find /usr/obj/amd64_clang/amd64.amd64/ -name autoload.o -exec ls -lT = {} \; | more -rw-r--r-- 1 root wheel 2896 Nov 3 00:10:12 2017 = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/boot/efi/loader/a= utoload.o (So the .o is about a year later.) # which cc /usr/bin/cc # find /usr/obj/amd64_clang/amd64.amd64/ -name cc -print | more = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/inc= lude/netinet/cc = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG/mod= ules/usr/src/sys/modules/cc = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/netin= et/cc = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/includ= e/netinet/cc It appears that /usr/bin was not part of the path at the time of the failure. As for the commands. . . (I isolated CC=3D on its own lines.) Script started on Fri Nov 3 00:52:26 2017 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -dM -j4 installworld --- installworld --- make[1]: = "/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/compiler-metadata.mk= " line 1: Using cached compiler metadata from build at FreeBSDx64OPC on = Thu Nov 2 23:02:54 PDT 2017 --- __installcheck_UGID --- --- __installcheck_sh_check --- --- installworld --- mkdir -p /tmp/install.hnB8rBdc progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp = date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb = rm sed services_mkdb sh strip sysctl test true uname wc zic tzsetup = makewhatis; do if progpath=3D`which $prog`; then echo $progpath; else = echo "Required tool $prog not found in PATH." >&2; exit 1; fi; = done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort = -u | while read line; do $line; if [ "$2 $3" !=3D "not found" ]; then = echo $2; else echo "Required library $1 not found." >&2; exit 1; = fi; done); cp $libs $progs /tmp/install.hnB8rBdc cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hnB8rBdc/locale cd /usr/src; COMPILER_VERSION=3D50000 COMPILER_FEATURES=3Dc++11 = COMPILER_TYPE=3Dclang COMPILER_FREEBSD_VERSION=3D1200007 = MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D CC=3D"cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" CXX=3D"c++ -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" = CPP=3D"cpp -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" = AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" = RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" = PATH=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr= /sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/= bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin:/u= sr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/a= md64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/tmp/install.hnB8rB= dc LD_LIBRARY_PATH=3D/tmp/install.hnB8rBdc = PATH_LOCALE=3D/tmp/install.hnB8rBdc/locale make -f Makefile.inc1 = __MAKE_SHELL=3D/tmp/install.hnB8rBdc/sh reinstall; = COMPILER_VERSION=3D50000 COMPILER_FEATURES=3Dc++11 COMPILER_TYPE=3Dclang= COMPILER_FREEBSD_VERSION=3D1200007 MACHINE_ARCH=3Damd64 MACHINE=3Damd64= CPUTYPE=3D CC=3D"cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" = CXX=3D"c++ -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" = CPP=3D"cpp -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" = AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" = RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" = PATH=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr= /sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/= bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin:/u= sr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/a= md64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/tmp/install.hnB8rB= dc LD_LIBRARY_PATH=3D/tmp/install.hnB8rBdc = PATH_LOCALE=3D/tmp/install.hnB8rBdc/locale rm -rf /tmp/install.hnB8rBdc --- reinstall --- . . . # more = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/compiler-metadata.mk .info Using cached compiler metadata from build at FreeBSDx64OPC on Thu = Nov 2 23:02:54 PDT 2017 COMPILER_VERSION=3D50000 COMPILER_TYPE=3Dclang COMPILER_FEATURES=3Dc++11 COMPILER_FREEBSD_VERSION=3D1200007 LINKER_VERSION=3D21750 LINKER_TYPE=3Dbfd .export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES = COMPILER_FREEBSD_VERSION LINKER_VERSION LINKER_TYPE # more /root/src.configs/make.conf CFLAGS.gcc+=3D -v # more /root/src.configs/src.conf.amd64-clang.amd64-host TO_TYPE=3Damd64 # KERNCONF=3DGENERIC-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLVM_LIBUNWIND=3D WITH_LLDB=3D #PORTS_MODULES=3Demulators/virtualbox-ose-additions # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net >>> . . . >>> Script started on Thu Nov 2 18:34:57 2017 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>>=20 >>> vs. >>>=20 >>> Script started on Thu Nov 2 18:34:57 2017 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 = make -j4 buildworld buildkernel >>>=20 >>>=20 >>> # svnlite status -u -r325351 /usr/src | sort >>> * 320623 = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h >>> ? /usr/src/sys/amd64/conf/GENERIC-DBG >>> ? /usr/src/sys/amd64/conf/GENERIC-NODBG >>> ? /usr/src/sys/arm/conf/GENERIC-DBG >>> ? /usr/src/sys/arm/conf/GENERIC-NODBG >>> ? /usr/src/sys/arm64/conf/GENERIC-DBG >>> ? /usr/src/sys/arm64/conf/GENERIC-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG >>> M 325351 = /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp >>> M 325351 = /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp >>> M 325351 /usr/src/crypto/openssl/crypto/armcap.c >>> M 325351 /usr/src/lib/libkvm/kvm_powerpc.c >>> M 325351 /usr/src/lib/libkvm/kvm_private.c >>> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c >>> M 325351 /usr/src/sys/arm64/arm64/identcpu.c >>> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >>> M 325351 /usr/src/sys/boot/ofw/Makefile.inc >>> M 325351 /usr/src/sys/boot/powerpc/Makefile.inc >>> M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile >>> M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile >>> M 325351 /usr/src/sys/boot/uboot/Makefile.inc >>> M 325351 /usr/src/sys/conf/kmod.mk >>> M 325351 /usr/src/sys/conf/ldscript.powerpc >>> M 325351 /usr/src/sys/kern/subr_pcpu.c >>> M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c >>> M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c >>> M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c >>> M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c >>> M 325351 /usr/src/sys/powerpc/powerpc/trap.c >>>=20 >>>=20 >>> -------------------------------------------------------------- >>>>>> stage 5.1: building lib32 shim libraries >>> -------------------------------------------------------------- >>> . . . >>> --- obj --- >>> --- lib/libgcc_eh__PL --- >>> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /lib/libgcc_eh/libunwind.o >>> --- gnu/lib/libssp/libssp_nonshared__PL --- >>> Building = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64= /gnu/lib/libssp/libssp_nonshared/_libinstall >>> . . . >>> . . . >>>=20 >>> And so on. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2017-Nov-2, at 5:30 PM, Bryan Drewery = wrote: >>=20 >> On 11/2/17 3:44 PM, Mark Millard wrote: >>>> Author: bdrewery >>>> Date: Thu Nov 2 22:23:00 2017 >>>> New Revision: 325347 >>>> URL:=20 >>>> https://svnweb.freebsd.org/changeset/base/325347 >>>>=20 >>>>=20 >>>> Log: >>>> Something is very wrong >>>>=20 >>>> Modified: >>>> head/Makefile >>>>=20 >>>> Modified: head/Makefile >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >>>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >>>> @@ -1,3 +1,4 @@ >>>> +.error Bad revision, please wait for a fix in head >>>> # >>>> # $FreeBSD$ >>>> # >>>=20 >>> I just happened to have started a cross build before >>> this showed up based on -r325332 . It got: >>>=20 >>> --- clang-tblgen.full --- >>> c++: error: no such file or directory: = '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/= clang/libllvmminimal/libllvmminimal.a' >>> *** [clang-tblgen.full] Error code 1 >>=20 >> Someone else reported this one as well but I have not been able to >> reproduce it yet. >>=20 >> I've tweaked the commit causing it though, r325329. Fixed in = r325350. >>=20 >>>=20 >>> But find shows: >>>=20 >>> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name = "libllvmminimal*" -print | more >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a.meta >>>=20 >>> Comparing side-by-side shows obj-cross-tools vs. >>> obj-bootstrap-tools : >>>=20 >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/c= lang/libllvmminimal/libllvmminimal.a >>> = /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/l= ib/clang/libllvmminimal/libllvmminimal.a >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>=20 >>=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Nov 3 17:44:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 467A9E5744E for ; Fri, 3 Nov 2017 17:44:49 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EFE2F6D1B0 for ; Fri, 3 Nov 2017 17:44:48 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id ECF35E5744C; Fri, 3 Nov 2017 17:44:48 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC772E5744B for ; Fri, 3 Nov 2017 17:44:48 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74ACE6D1AE; Fri, 3 Nov 2017 17:44:48 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xLPJN9b++dAVmeiWSQYFbdmd8a3fqHevrSmIJhGqO0A=; b=Pt5RSzsd4JcAFcnsn5MrWRZKkjB+HcG+QH4S0F0SVUY8gPvVm74DxhfHJnkhGoYSssGw/b0eqWDuhufGCppm+f+0+tDCmXTZIlS2/an7+VQbvp79fEPIjwNw68lUiDjRjQs5H7wXNmPHGThP+0qLoehK+J+II+b3Avk0wrP4+HI= Received: from BY2PR05CA048.namprd05.prod.outlook.com (10.141.250.38) by MWHPR05MB3615.namprd05.prod.outlook.com (10.174.251.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Fri, 3 Nov 2017 17:44:33 +0000 Received: from CO1NAM05FT031.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::202) by BY2PR05CA048.outlook.office365.com (2a01:111:e400:2c5f::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.218.6 via Frontend Transport; Fri, 3 Nov 2017 17:44:33 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT031.mail.protection.outlook.com (10.152.96.143) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.197.9 via Frontend Transport; Fri, 3 Nov 2017 17:44:33 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 3 Nov 2017 10:44:15 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id vA3HiFNU030368; Fri, 3 Nov 2017 10:44:15 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 66B86385567; Fri, 3 Nov 2017 10:44:15 -0700 (PDT) To: Remko Lodder CC: Postmaster Team , Subject: Re: can't subscribe to freebsd-* lists? In-Reply-To: <6EE47166-A74F-4A30-9AFE-CC9D1D77A2B7@FreeBSD.org> References: <8104.1509593424@kaos.jnpr.net> <20171102040727.GX1240@fc.opsec.eu> <20709.1509643112@kaos.jnpr.net> <20171102185239.GZ1240@fc.opsec.eu> <24123.1509655316@kaos.jnpr.net> <20171102210854.GA1240@fc.opsec.eu> <25743.1509660420@kaos.jnpr.net> <40875.1509722101@kaos.jnpr.net> <6EE47166-A74F-4A30-9AFE-CC9D1D77A2B7@FreeBSD.org> Comments: In-reply-to: Remko Lodder message dated "Fri, 03 Nov 2017 17:42:09 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43661.1509731055.1@kaos.jnpr.net> Date: Fri, 3 Nov 2017 10:44:15 -0700 Message-ID: <43662.1509731055@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(2980300002)(189002)(199003)(24454002)(106466001)(7696004)(117636001)(6246003)(97736004)(55016002)(6266002)(76176999)(53936002)(50466002)(54906003)(9686003)(107886003)(16586007)(50986999)(97756001)(105596002)(93886005)(316002)(68736007)(5660300001)(50226002)(2810700001)(46406003)(86362001)(7126002)(2906002)(76506005)(229853002)(47776003)(2950100002)(23726003)(77096006)(478600001)(97876018)(356003)(53416004)(6916009)(450100002)(8936002)(81156014)(8676002)(4326008)(189998001)(69596002)(81166006)(53546010)(305945005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3615; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT031; 1:EAbkQW4BpQAIMCp0sKL/X1EjL0q7ubMNGbkhq8WiFo6thL/e1fyzB6xUvrp3XqIO6ByDS8DWHz8u54FArSlriCBbYRShLyRzy2Zj05oYnBUXWKGJIWr7TeVJi8nRONfv X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9a7d1d3d-94fc-44db-087c-08d522e28b25 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB3615; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 3:FaxnTfZQx3xPqhYN9vfDXMc0sHqrtpU78Jn9Z2AU17sZJjvJWL2VD4FgAoAvXQZUf+GTSvG3T+6IDhwYBTcDFJoUU/gytPPvQNJvZFTsN/j3jZYEBZmKxxxa8KsO1IqHI1RNWhenEY2usUo2DjfBqIBGrLRpqzHj85LPZuys0e/qlQbf9oMbAGVWAsdISbRbjxkm5E2OjoP0rXJhLBg4nqPfcWAV423XaMIeg1ag6QdvDK2lWlV/z+3wlnk2G8rEDoFcwQBus4wv44tXHPUNuMk8XZ4Pbt6SINU28u+gawoGrSEYN7GgCKRVWKEGBnpMljuxVIS808JI68qZmLTvIFJV52nwyICQuNVSHxkphNo=; 25:MnVkve7ph7h5Q8FZ3PgRea/S7J/GucDWQmHKo+8ulntAR/1I6mFRq5V09WNwppuhB/jLx6jL0hB2onSwtMOtZF90PB2CWTUMY/O1YI435eHppW/xnZlIdbMvAPATw0V/51uCjLHWgd0XhRJOig/3TYFz6SG4TtVM6QoJqcPwCpznB9HT52nyhO2yUb61xrxns74HW4yudanS0u0E4lEjBIc2fuuSKPKxENePEk/TdCqU/WWCV0cUOlo9y9vXJ4HKiRODjUtlrQXlteAOkFAa+8AgARmqx8TrUmqdc0mWf/gnXOLm6/T62RRhj5a9xOhbKH59XTeoYYxKSK8FuVH27g== X-MS-TrafficTypeDiagnostic: MWHPR05MB3615: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 31:rMhBevqvyitZZOW84Lp7ejf69fX3spsUMbIplvHAD3e3UgV2qu20e7mc/GISzHSODDWi7h48CQ9ID9eSahnMLmMV3U/u90c6ZdBNMnidw9dmCOG2rmbNy8Y7vUDoJhU+EiWAbS12GLfgux8nJSfNc9aSo84wzvlj4p1YXI28iFNnRnGz9aBpWXaPcCAz6bBEgCYvL1GsL62YbuMvd2WVntI3OD/kSOL/4EOf6recWDM=; 20:lTS0rxVRDwB5ejdWEs56BUuU7Lnve1jSYohGPXIgpNvAS/bBygLcBJfWWJAClli400iAxk8YFOhFMj1GBt9SSu3WG66Pwuk0hb81SzoU6ugEoRz+F2CP1SXY6Df6U2GCD/kdr0jzVH9YwFR4npiWHuASlYPHhtp+qWB2KocKFbFXt5uCZWsPmqxmcDEXLVsPRvQsFgrxOCxuhfrG8zyEXFRxinMvFadz9X8YxbOQ6bJ56+nBMXbLvctkszMZdHrSwm3DTb7uJUGh/Icrnu2UXnExHGZqvBnCxwE7PNQFdef+QDr7Y6rEGmCw+RHh6owJSFxu0rkoIJQEQ0xobcqPLOfA3b56q7SLJ8mybJAaDPLBAcEauPbE5EOchaBIhm2ej8mqMjSFuu9NIIL5xXVk6+3LtRK5IH85BhQpWgjd10p5AaVi3EeP3oSla87SfoYX216Uy8cPywMMhrNy1HzqRacYnFVsamA0O+9cDDM8jNpFIRTrE/e0I97meWhuX3Bl X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93003095)(10201501046)(3231021)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3615; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3615; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 4:FeLNoR1ES0NNSsl/OUZwzO2js9X9ux8sTypq0YdZQIuo+fjxGCpWQajwQGk1TvhszS4yvrAR5v9rMnrqNTUWoldWF9vPC1EU9Ugwrn3Md9Drsigvd0WYFJ+RZ9vJHLmjz7Uzop4kVfDgUY0e/WHugHO4qh9kOucE6bLHjhlT1DheOIggxaxSxTNrAdh5jphVlKdvlDkxfN397Xu9rrFEihMBHA//TjWdQEvBU/CrNa7uh18tkUKGHmHE7Omfm8jSmVeae5090BY6i84grw1Xfw== X-Forefront-PRVS: 0480A51D4A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3615; 23:9xF+BEs2x1Rd7ra853xJ0PvRW/hL8IL/fdx6VFwP+?= =?us-ascii?Q?/hC7guIyDLIJ0EuZfV5Ru+DFmwiVfGcqccgX3Wh0fUg4NLMIu8qzj8QzdxNv?= =?us-ascii?Q?S8MZ2MBKFKyB6l9OH9t1/g7FUkhPtST6yqoS7Zu5XVkZdo4pAb+nXdoTY5zX?= =?us-ascii?Q?tWWMf7Q6bdJlQv5nTn3T25MzmU97NOpIsAEJMsgvwP8yQlmxDe83WdbYfp3X?= =?us-ascii?Q?K47wUJRANX/bQ44un2kggykviQASR5zqyDPSilkve9tIBlmACqNdieXNuifj?= =?us-ascii?Q?uiE300AiDOgTQUiTepJ0dGe8zcbLOAsYBHzM89ndcqbCPoVquNBqOo5AHRcO?= =?us-ascii?Q?CctVv2c1GNzn9micbgR/62TnWOeX1xOmj0/nKE6oHqq1rGx8/qVbC21FWP0L?= =?us-ascii?Q?d/e+O2M0XUdbJchDlg2ZmRkBOMQQJ6SJ0wM1Lq7cXI27vKf332WdFUHEByv6?= =?us-ascii?Q?27oC4Vv2sitZpfQjKamNtxaygy6MmNOT9ql6kwwEr7AB65GTVZUWGHzBc3K2?= =?us-ascii?Q?bu6c9T7D1WUshiZdfAahzNjYSA2hYGYGpbCqSETFqqmY8cnsLNBu8hRpplCQ?= =?us-ascii?Q?r30g+hKdoZKarnofDGBUMPxrjcnXrLAt+BQ8jp/Lyh/73w4IJsz9CziJvJfz?= =?us-ascii?Q?HCf7Pc8dRDyYDTwy4jL/OoNxZiH5VwkG0qHbpAd3co3Wu+OI/C0zlHJC3A1T?= =?us-ascii?Q?mxa1T6Y580/I6hQw6gFD7NdLzc9BwNErOZdmpYTrsLRAIkiSfWedxTJaq0EO?= =?us-ascii?Q?fdHGf4j8w0Di6frj7ag8VDX2UgDI0keuQt+l2gYzV2iUQdO8TZWMzaZ6r/F9?= =?us-ascii?Q?RF3SbO7K+qh+L9DgED4TX2sTF3gWVn/KDsCHmeqfKDKpQDUSUyiuwv2s2wgA?= =?us-ascii?Q?FxheCir30oeCVAQ72E0eA6K5DueNmy0Kudd+KjEweMu1+ecPn4gfdzGHahXY?= =?us-ascii?Q?shx847b7Arw9izmmaIE0VQMRcaxF9VE4Y+/3cGnEr4EFA7G2TgWnaWV+M+U4?= =?us-ascii?Q?ZA9CMNxlQNNC74q+c8jOPlIWwKBfXDqt8+0VjWOOEz5lw5JSJhLgZDSr9xJW?= =?us-ascii?Q?beFMvcQ0G+FK/ao6pnmoXwl/A440aHmwRvpadGEYqJbreSVTz7YTUrucKcqU?= =?us-ascii?Q?pKGmKZHOu7xqdhh2DP/IQuE2NTfAfYxOQ/BHY0PS5NcA6JGr47zdAnLAmCfV?= =?us-ascii?Q?ooJSFLcs7hJrJs8+F1LVAJDuQPrBkScyqPSHu4SXVGu44puXLxj0aH6kAD1I?= =?us-ascii?Q?ziXRtWYEnY+OzNfQ/BcYxdyjjMDeqRPDdKh1ZgdM1RsGga9AyE8j3zt2DZqS?= =?us-ascii?Q?OPUoLoLIQH8uAzfsypU5IsZmH4vhoLGGFJHzMihdYOY?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 6:RoqrtMumVmhKzXByMzhXT/HnrVraIwfCdxhbf+vj+e99bLZYQ+G+R2aDdMCj6oV6Ez9A9OrBWa7OM7yRc+mawSZBxmclvhRodjYs8F9es2uKFBadUEBgCYCS/Z2yQStofaWEICkZBgiu7tOG59sdGhcyPCmjtQx+n3qYCV0OFaDosGTLMZosR03gLp3qmXJyNyMOgYKjqqJz7fxhISwcwLVqrAkdkZ6MEvK93X7VgguAUsjsBmo9aLBm5oe+B2RTTWbgy9bEHjBrMhBk6u1vb83pCG1VsfIQ3LHSZDGv3IG1rGDVI4AAalZMpPqaqUFpng/SzvkVe7CxpY5GwzN2yGqi0R9obeXttqr4DiPriiA=; 5:3JJCgfXpGFGwbOtcWA3fyol0dseuJii/gK1IAI+dgayTdF0FaSZndprh/nwf5N8uCXmoFCbx+Cso14oFYojfgPA9AwPEMo8AqVymnbGkSd07WrFCC3aQiHnnFfEP2LrxR1ArHYTnhh3oavMuuh1g2c3v3XePGbEi4LFq3x0MzW4=; 24:IlYsqz1r2Sue8mZxX2JZtuD6b3vquEZzeCZkwFZG5GO8Yjld7ic7eGXrIBBVwe5RS6Fk0Xp3RO7d9hrhgNQJa0hkg2UeH6AsS2gq+Qwncq4=; 7:dCHpfB5edVe2EoQDiF08sHpA+CytGT7yqRiVKxRIhePh9mENOd3NWHci58/9fz2c1MO4pTfex6En2FDTld0HYb6LusueoGRaA7nOXvPpt0TYivT0PFv2ThlALI9TBgI1V0CgS49ARgmAAtQ9hzsR9Lz7NimDywxRrwhdeo52Gv5h/8B1yG/VqMPy6qtLieRJbPm6cEdkWpd1jl0lCKLLLI/edvySZqR2BvWgRdRkw66eQyTDsU0hfhuGNRbpm1kk SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 17:44:33.2393 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a7d1d3d-94fc-44db-087c-08d522e28b25 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3615 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:44:49 -0000 Remko Lodder wrote: Thanks very much, Remko, just got the welcome messages. So issue seems limited to the confirmation mails, maybe they look too much like spam? > > > Hi Simon, > > > On 3 Nov 2017, at 16:16, Remko Lodder wrote: > > > > > I have added you to the freebsd-hackers and freebsd-security lists. > Please let me/us know when things do not go as planned ;-) > > Cheers > Remko From owner-freebsd-hackers@freebsd.org Fri Nov 3 18:31:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F7FCE582E5; Fri, 3 Nov 2017 18:31:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEE906E546; Fri, 3 Nov 2017 18:31:39 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id EA6031FC6F; Fri, 3 Nov 2017 18:31:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 26AA926AA; Fri, 3 Nov 2017 18:31:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id EYYlbQSrTrpQ; Fri, 3 Nov 2017 18:31:32 +0000 (UTC) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com C7C5726A3 To: Mark Millard Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> Date: Fri, 3 Nov 2017 11:31:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Fmll73KadUoXti7Bl4A305nXqQsPrFkBH" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 18:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fmll73KadUoXti7Bl4A305nXqQsPrFkBH Content-Type: multipart/mixed; boundary="Sj9WbwQKuSxefhBt9QejV7GQV1LhtNgAI"; protected-headers="v1" From: Bryan Drewery To: Mark Millard Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Message-ID: <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> In-Reply-To: <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> --Sj9WbwQKuSxefhBt9QejV7GQV1LhtNgAI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/3/17 1:52 AM, Mark Millard wrote: > I did get another problem after buildworld, buildkernel, installkernel > without future source code dates: the installworld got a "cc not found"= > for the amd64 native build based on -r325351 --that also appears to be > set up to report: >=20 > ERROR-tried-to-rebuild-during-make-install >=20 > if cc had been found: >=20 > .if defined(SRCTOP) > # Prevent rebuilding during install to support read-only objdirs. > .if ${.TARGETS:M*install*} =3D=3D ${.TARGETS} && empty(.MAKE.MODE:Mmeta= ) > CFLAGS+=3D ERROR-tried-to-rebuild-during-make-install > .endif=20 > .endif=20 >=20 This one usually only happens if it is trying to compile at installtime, which usually means a file is missing (wrong OBJDIR perhaps) or the timestamps are off. I'll play with this more and see what I can come up with, but I didn't run into anything like this myself yet. > is involved in: >=20 > Script started on Fri Nov 3 00:52:26 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/n= ull SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host WITH= _META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 make= -dM -j4 installworld > . . . > --- realinstall_subdir_sys --- > --- autoload.o --- > --- realinstall_subdir_secure --- > rm -f /usr/share/openssl/man/man3/SSL_set_generate_session_id.3 /usr/sh= are/openssl/man/man3/SSL_set_generate_session_id.3.gz; install -l h /us= r/share/openssl/man/man3/SSL_CTX_set_generate_session_id.3.gz /usr/share/= openssl/man/man3/SSL_set_generate_session_id.3.gz > --- realinstall_subdir_sys --- > cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd64_clang/= amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/us= r/src/amd64.amd64/tmp/usr/bin -O2 -pipe -ffreestanding -Wformat -mno-m= mx -mno-sse -mno-avx -msoft-float -fshort-wchar -mno-red-zone -mno-aes -D= LOADER_UFS_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MB= R_SUPPORT -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/= boot/zfs -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader -= I/usr/src/sys/boot/efi/loader/arch/amd64 -I/usr/src/sys/boot/efi/include = -I/usr/src/sys/boot/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/i= nclude -I/usr/src/sys -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DS= MBIOS_SERIAL_NUMBERS -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot= /ficl -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FO= RTH -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototype= s -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum= -conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qun= used-arguments ERROR-tried-to-rebuild-during-make-install -c /usr/src/sy= s/boot/efi/loader/autoload.c -o autoload.o > sh: cc: not found > --- realinstall_subdir_secure --- > rm -f /usr/share/openssl/man/man3/SSL_CTX_get_info_callback.3 /usr/shar= e/openssl/man/man3/SSL_CTX_get_info_callback.3.gz; install -l h /usr/sh= are/openssl/man/man3/SSL_CTX_set_info_callback.3.gz /usr/share/openssl/ma= n/man3/SSL_CTX_get_info_callback.3.gz > --- realinstall_subdir_sys --- > *** [autoload.o] Error code 127 >=20 > make[7]: stopped in /usr/src/sys/boot/efi/loader > 1 error >=20 > make[7]: stopped in /usr/src/sys/boot/efi/loader > *** [realinstall_subdir_sys/boot/efi/loader] Error code 2 >=20 >=20 > Or without -j4: >=20 > Script started on Fri Nov 3 01:38:54 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/n= ull SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host WITH= _META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 make= -dM installworld > . . . > =3D=3D=3D> sys/boot/libsa32 (install) > =3D=3D=3D> sys/boot/zfs (install) > =3D=3D=3D> sys/boot/zfs32 (install) > =3D=3D=3D> sys/boot/ficl32 (install) > =3D=3D=3D> sys/boot/efi (install) > =3D=3D=3D> sys/boot/efi/libefi (install) > =3D=3D=3D> sys/boot/efi/loader (install) > cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd64_clang/= amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/us= r/src/amd64.amd64/tmp/usr/bin -O2 -pipe -ffreestanding -Wformat -mno-m= mx -mno-sse -mno-avx -msoft-float -fshort-wchar -mno-red-zone -mno-aes -D= LOADER_UFS_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MB= R_SUPPORT -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/= boot/zfs -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader -= I/usr/src/sys/boot/efi/loader/arch/amd64 -I/usr/src/sys/boot/efi/include = -I/usr/src/sys/boot/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/i= nclude -I/usr/src/sys -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DS= MBIOS_SERIAL_NUMBERS -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot= /ficl -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FO= RTH -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototype= s -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum= -conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qun= used-arguments ERROR-tried-to-rebuild-during-make-install -c /usr/src/sy= s/boot/efi/loader/autoload.c -o autoload.o > /tmp/install.2mZZVhR0/sh: cc: not found > *** Error code 127 >=20 > Stop. > make[7]: stopped in /usr/src/sys/boot/efi/loader > *** Error code 1 >=20 >=20 >=20 > I'll note: >=20 > # ls -lT /usr/src/sys/boot/efi/loader/autoload.c > -rw-r--r-- 1 root wheel 1522 Nov 3 02:27:17 2016 /usr/src/sys/boot/= efi/loader/autoload.c >=20 > # find /usr/obj/amd64_clang/amd64.amd64/ -name autoload.o -exec ls -lT = {} \; | more > -rw-r--r-- 1 root wheel 2896 Nov 3 00:10:12 2017 /usr/obj/amd64_cla= ng/amd64.amd64/usr/src/amd64.amd64/sys/boot/efi/loader/autoload.o >=20 > (So the .o is about a year later.) >=20 > # which cc > /usr/bin/cc >=20 > # find /usr/obj/amd64_clang/amd64.amd64/ -name cc -print | more > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/= include/netinet/cc > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG/= modules/usr/src/sys/modules/cc > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/ne= tinet/cc > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/inc= lude/netinet/cc >=20 > It appears that /usr/bin was not part of the path at > the time of the failure. >=20 > As for the commands. . . > (I isolated CC=3D on its own lines.) >=20 > Script started on Fri Nov 3 00:52:26 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/n= ull SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host WITH= _META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 make= -dM -j4 installworld > --- installworld --- > make[1]: "/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/compiler= -metadata.mk" line 1: Using cached compiler metadata from build at FreeBS= Dx64OPC on Thu Nov 2 23:02:54 PDT 2017 > --- __installcheck_UGID --- > --- __installcheck_sh_check --- > --- installworld --- > mkdir -p /tmp/install.hnB8rBdc > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp da= te echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm = sed services_mkdb sh strip sysctl test true uname wc zic tzsetup makewh= atis; do if progpath=3D`which $prog`; then echo $progpath; else echo = "Required tool $prog not found in PATH." >&2; exit 1; fi; done); libs= =3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while = read line; do $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; e= lse echo "Required library $1 not found." >&2; exit 1; fi; done); cp= $libs $progs /tmp/install.hnB8rBdc > cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hnB8rBdc/locale > cd /usr/src; COMPILER_VERSION=3D50000 COMPILER_FEATURES=3Dc++11 COMPI= LER_TYPE=3Dclang COMPILER_FREEBSD_VERSION=3D1200007 MACHINE_ARCH=3Damd64= MACHINE=3Damd64 CPUTYPE=3D >=20 > CC=3D"cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd64_= clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.am= d64/usr/src/amd64.amd64/tmp/usr/bin" >=20 > CXX=3D"c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd= 64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64= =2Eamd64/usr/src/amd64.amd64/tmp/usr/bin" CPP=3D"cpp -target x86_64-unkn= own-freebsd12.0 --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd6= 4.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/us= r/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"= objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" PATH=3D/usr/obj/amd64= _clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64= _clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_= clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/amd64_clang= /amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_clang/amd64.= amd64/usr/src/amd64.amd64/tmp/usr/bin:/tmp/install.hnB8rBdc LD_LIBRARY_P= ATH=3D/tmp/install.hnB8rBdc PATH_LOCALE=3D/tmp/install.hnB8rBdc/locale m= ake -f Makefile.inc1 __MAKE_SHELL=3D/tmp/install.hnB8rBdc/sh reinstall= ; COMPILER_VERSION=3D50000 COMPILER_FEATURES=3Dc++11 COMPILER_TYPE=3Dc= lang COMPILER_FREEBSD_VERSION=3D1200007 MACHINE_ARCH=3Damd64 MACHINE=3D= amd64 CPUTYPE=3D CC=3D"cc -target x86_64-unknown-freebsd12.0 --sysroot=3D= /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64= _clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" CXX=3D"c++ -target x= 86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/us= r/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.am= d64/tmp/usr/bin" CPP=3D"cpp -target x86_64-unknown-freebsd12.0 --sysroot= =3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/am= d64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin" AS=3D"as" AR=3D"a= r" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib= STRINGS=3D SIZE=3D"size" PATH=3D/usr/obj/amd64_clang/amd64.amd64/usr/sr= c/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/sr= c/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src= /amd64.amd64/tmp/legacy/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd6= 4.amd64/tmp/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64= /tmp/usr/bin:/tmp/install.hnB8rBdc LD_LIBRARY_PATH=3D/tmp/install.hnB8rB= dc PATH_LOCALE=3D/tmp/install.hnB8rBdc/locale rm -rf /tmp/install.hnB8rB= dc > --- reinstall --- > . . . >=20 > # more /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/compiler-me= tadata.mk > .info Using cached compiler metadata from build at FreeBSDx64OPC on Thu= Nov 2 23:02:54 PDT 2017 > COMPILER_VERSION=3D50000 > COMPILER_TYPE=3Dclang > COMPILER_FEATURES=3Dc++11 > COMPILER_FREEBSD_VERSION=3D1200007 > LINKER_VERSION=3D21750 > LINKER_TYPE=3Dbfd > .export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES COMPILER_FR= EEBSD_VERSION LINKER_VERSION LINKER_TYPE >=20 >=20 > # more /root/src.configs/make.conf > CFLAGS.gcc+=3D -v >=20 > # more /root/src.configs/src.conf.amd64-clang.amd64-host > TO_TYPE=3Damd64 > # > KERNCONF=3DGENERIC-NODBG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > #WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > WITHOUT_LLD_IS_LD=3D > WITH_LLVM_LIBUNWIND=3D > WITH_LLDB=3D > #PORTS_MODULES=3Demulators/virtualbox-ose-additions > # > WITH_BOOT=3D > WITH_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >>>> . . . >=20 >=20 >>>> Script started on Thu Nov 2 18:34:57 2017 >>>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/de= v/null SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host W= ITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 m= ake -j4 buildworld buildkernel >>>> >>>> vs. >>>> >>>> Script started on Thu Nov 2 18:34:57 2017 >>>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/de= v/null SRC_ENV_CONF=3D/root/src.configs/src.conf.amd64-clang.amd64-host W= ITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/amd64_clang/amd64.amd64 m= ake -j4 buildworld buildkernel >>>> >>>> >>>> # svnlite status -u -r325351 /usr/src | sort >>>> * 320623 /usr/src/contrib/jemalloc/include/jemalloc/interna= l/tsd.h >>>> ? /usr/src/sys/amd64/conf/GENERIC-DBG >>>> ? /usr/src/sys/amd64/conf/GENERIC-NODBG >>>> ? /usr/src/sys/arm/conf/GENERIC-DBG >>>> ? /usr/src/sys/arm/conf/GENERIC-NODBG >>>> ? /usr/src/sys/arm64/conf/GENERIC-DBG >>>> ? /usr/src/sys/arm64/conf/GENERIC-NODBG >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG >>>> M 325351 /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFra= meLowering.cpp >>>> M 325351 /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.= cpp >>>> M 325351 /usr/src/crypto/openssl/crypto/armcap.c >>>> M 325351 /usr/src/lib/libkvm/kvm_powerpc.c >>>> M 325351 /usr/src/lib/libkvm/kvm_private.c >>>> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c >>>> M 325351 /usr/src/sys/arm64/arm64/identcpu.c >>>> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >>>> M 325351 /usr/src/sys/boot/ofw/Makefile.inc >>>> M 325351 /usr/src/sys/boot/powerpc/Makefile.inc >>>> M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile >>>> M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile >>>> M 325351 /usr/src/sys/boot/uboot/Makefile.inc >>>> M 325351 /usr/src/sys/conf/kmod.mk >>>> M 325351 /usr/src/sys/conf/ldscript.powerpc >>>> M 325351 /usr/src/sys/kern/subr_pcpu.c >>>> M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c >>>> M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c >>>> M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c >>>> M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c >>>> M 325351 /usr/src/sys/powerpc/powerpc/trap.c >>>> >>>> >>>> -------------------------------------------------------------- >>>>>>> stage 5.1: building lib32 shim libraries >>>> -------------------------------------------------------------- >>>> . . . >>>> --- obj --- >>>> --- lib/libgcc_eh__PL --- >>>> Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-li= b32/amd64.amd64/lib/libgcc_eh/libunwind.o >>>> --- gnu/lib/libssp/libssp_nonshared__PL --- >>>> Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-li= b32/amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall >>>> . . . >>>> . . . >>>> >>>> And so on. >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2017-Nov-2, at 5:30 PM, Bryan Drewery wrote= : >>> >>> On 11/2/17 3:44 PM, Mark Millard wrote: >>>>> Author: bdrewery >>>>> Date: Thu Nov 2 22:23:00 2017 >>>>> New Revision: 325347 >>>>> URL:=20 >>>>> https://svnweb.freebsd.org/changeset/base/325347 >>>>> >>>>> >>>>> Log: >>>>> Something is very wrong >>>>> >>>>> Modified: >>>>> head/Makefile >>>>> >>>>> Modified: head/Makefile >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) >>>>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) >>>>> @@ -1,3 +1,4 @@ >>>>> +.error Bad revision, please wait for a fix in head >>>>> # >>>>> # $FreeBSD$ >>>>> # >>>> >>>> I just happened to have started a cross build before >>>> this showed up based on -r325332 . It got: >>>> >>>> --- clang-tblgen.full --- >>>> c++: error: no such file or directory: '/usr/obj/bpim3_clang/arm.arm= v7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvm= minimal.a' >>>> *** [clang-tblgen.full] Error code 1 >>> >>> Someone else reported this one as well but I have not been able to >>> reproduce it yet. >>> >>> I've tweaked the commit causing it though, r325329. Fixed in r325350= =2E >>> >>>> >>>> But find shows: >>>> >>>> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libll= vmminimal*" -print | more >>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-t= ools/lib/clang/libllvmminimal >>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-t= ools/lib/clang/libllvmminimal/libllvmminimal.a >>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-t= ools/lib/clang/libllvmminimal/libllvmminimal.a.meta >>>> >>>> Comparing side-by-side shows obj-cross-tools vs. >>>> obj-bootstrap-tools : >>>> >>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools= /lib/clang/libllvmminimal/libllvmminimal.a >>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-t= ools/lib/clang/libllvmminimal/libllvmminimal.a >>>> >>>> >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>> >>> >>> >> >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 --=20 Regards, Bryan Drewery --Sj9WbwQKuSxefhBt9QejV7GQV1LhtNgAI-- --Fmll73KadUoXti7Bl4A305nXqQsPrFkBH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAln8tgIACgkQNddxu25G l8/ABQgAj5T97PIOkH6FTVl34uOTDi1kGT2XU7bZLHWqAZfRdeP3g9i6fJqPDzV2 TTEmtsX1g5H+hmvCnl/G9TxQQ/tzSi4StKc/rYKica/nzYUdNDGiVqv3fqIqu/D5 mgT70TS2NIEZGMNusNRzzy3rVE6ak/wcWC6vDkU5OfTrPkBnseQsqT+fO6qnbtdK X+/V3kry4vxBMXtYYaghLZ6YIegsEZhrsi1VkuG0QTuSjGLREc0BbneNKQ6wjoJu sjVGkAGekH1UYXdEPhWMr0Myv1qtcZNlKuy4v5Wbac8Mc9Uzkfn7rQYZfe+A1HxR md9B+cCSHofUv8vQC2gUkNbpsoZcUw== =Apkb -----END PGP SIGNATURE----- --Fmll73KadUoXti7Bl4A305nXqQsPrFkBH-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 19:49:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0116CE5986F for ; Fri, 3 Nov 2017 19:49:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-115.reflexion.net [208.70.210.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2A95708FA for ; Fri, 3 Nov 2017 19:49:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17399 invoked from network); 3 Nov 2017 19:42:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 19:42:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 03 Nov 2017 15:42:39 -0400 (EDT) Received: (qmail 26719 invoked from network); 3 Nov 2017 19:42:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 19:42:38 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2B571EC92A1; Fri, 3 Nov 2017 12:42:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools From: Mark Millard In-Reply-To: <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> Date: Fri, 3 Nov 2017 12:42:37 -0700 Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <25840EFC-69DD-4A2A-B89A-0D6D51C9BA14@dsl-only.net> References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 19:49:21 -0000 On 2017-Nov-3, at 11:31 AM, Bryan Drewery wrote: > On 11/3/17 1:52 AM, Mark Millard wrote: >> I did get another problem after buildworld, buildkernel, = installkernel >> without future source code dates: the installworld got a "cc not = found" >> for the amd64 native build based on -r325351 --that also appears to = be >> set up to report: >>=20 >> ERROR-tried-to-rebuild-during-make-install >>=20 >> if cc had been found: >>=20 >> .if defined(SRCTOP) >> # Prevent rebuilding during install to support read-only objdirs. >> .if ${.TARGETS:M*install*} =3D=3D ${.TARGETS} && = empty(.MAKE.MODE:Mmeta) >> CFLAGS+=3D ERROR-tried-to-rebuild-during-make-install >> .endif=20 >> .endif=20 >>=20 >=20 > This one usually only happens if it is trying to compile at = installtime, > which usually means a file is missing (wrong OBJDIR perhaps) or the > timestamps are off. >=20 > I'll play with this more and see what I can come up with, but I didn't > run into anything like this myself yet. I locally forced a -dm on the ${MAKE} command involved and the result reported: Examining beforeinstall...non-existent....PHONY node...out-of-date. recheck(beforeinstall): update time from 16:00:00 Dec 31, 1969 to now Examining machine...modified 20:13:03 Nov 03, 2017...up-to-date. Examining x86...modified 20:13:07 Nov 03, 2017...up-to-date. Examining autoload.c...modified 2:27:17 Nov 03, 2016...up-to-date. Examining autoload.o...modified 0:10:12 Nov 03, 2017...modified before = source x86...out-of-date. cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp = -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 = -pipe -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -msoft-float = -fshort-wchar -mno-red-zone -mno-aes -DLOADER_UFS_SUPPORT = -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT = -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/boot/zfs = -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader = -I/usr/src/sys/boot/efi/loader/arch/amd64 = -I/usr/src/sys/boot/efi/include -I/usr/src/sys/boot/efi/include/amd64 = -I/usr/src/sys/contrib/dev/acpica/include -I/usr/src/sys = -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DSMBIOS_SERIAL_NUMBERS = -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot/ficl = -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FORTH = -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -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 = -Wno-unused-local-typedef -Wno-address-of-packed-member = -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -c = /usr/src/sys/boot/efi/loader/autoload.c -o autoload.o /tmp/install.intsn5IS/sh: cc: not found *** Error code 127 So far I've not found anything with matching times for: Examining machine...modified 20:13:03 Nov 03, 2017...up-to-date. Examining x86...modified 20:13:07 Nov 03, 2017...up-to-date. But the reason for rebuild is listed as: modified before source x86...out-of-date. I'll keep looking. The odd time (future) is in the ball park of others from when the virtual machine apparently had a bad time setting. I'm not sure if the x86 is a file vs. a directory here. A directory would seem a bit strange for forcing a rebuild. (Similarly for machine.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Nov 3 19:59:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B28A4E59CAA; Fri, 3 Nov 2017 19:59:48 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7831870E3A; Fri, 3 Nov 2017 19:59:48 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A277DCF0; Fri, 3 Nov 2017 19:59:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D31EA28E1; Fri, 3 Nov 2017 19:59:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id bROGNdKSJApM; Fri, 3 Nov 2017 19:59:43 +0000 (UTC) Subject: sys/boot machine symlink dirs causing rebuild [was Re: Example of Bryan Drewery's "Something is very wrong" ...] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com B140A28DC To: Mark Millard Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> <25840EFC-69DD-4A2A-B89A-0D6D51C9BA14@dsl-only.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Fri, 3 Nov 2017 12:59:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <25840EFC-69DD-4A2A-B89A-0D6D51C9BA14@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cpHBcDaQVNXKcv8H5hLaoTSPt7QovStJR" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 19:59:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cpHBcDaQVNXKcv8H5hLaoTSPt7QovStJR Content-Type: multipart/mixed; boundary="gH2GsuUNtt2oJg0voc1V9xcdpDwdJCvVs"; protected-headers="v1" From: Bryan Drewery To: Mark Millard Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Message-ID: Subject: sys/boot machine symlink dirs causing rebuild [was Re: Example of Bryan Drewery's "Something is very wrong" ...] References: <40F1D1F0-A67D-4BF9-9936-EF07A9E01912@dsl-only.net> <83ae760f-7bd5-811c-f32e-9d8f03074b49@FreeBSD.org> <20E6AE67-83F8-40D5-A4DA-01C02FA0A02B@dsl-only.net> <6E2B2A5E-A52E-4027-B73B-C6E78D9C0EED@dsl-only.net> <8D698E5D-C986-4FBA-BD56-6BA4E7D7F519@dsl-only.net> <12bff2b7-655d-b236-5f96-d405870e53d0@FreeBSD.org> <25840EFC-69DD-4A2A-B89A-0D6D51C9BA14@dsl-only.net> In-Reply-To: <25840EFC-69DD-4A2A-B89A-0D6D51C9BA14@dsl-only.net> --gH2GsuUNtt2oJg0voc1V9xcdpDwdJCvVs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/3/2017 12:42 PM, Mark Millard wrote: > On 2017-Nov-3, at 11:31 AM, Bryan Drewery wrote:= >=20 >> On 11/3/17 1:52 AM, Mark Millard wrote: >>> I did get another problem after buildworld, buildkernel, installkerne= l >>> without future source code dates: the installworld got a "cc not foun= d" >>> for the amd64 native build based on -r325351 --that also appears to b= e >>> set up to report: >>> >>> ERROR-tried-to-rebuild-during-make-install >>> >>> if cc had been found: >>> >>> .if defined(SRCTOP) >>> # Prevent rebuilding during install to support read-only objdirs. >>> .if ${.TARGETS:M*install*} =3D=3D ${.TARGETS} && empty(.MAKE.MODE:Mme= ta) >>> CFLAGS+=3D ERROR-tried-to-rebuild-during-make-install >>> .endif=20 >>> .endif=20 >>> >> >> This one usually only happens if it is trying to compile at installtim= e, >> which usually means a file is missing (wrong OBJDIR perhaps) or the >> timestamps are off. >> >> I'll play with this more and see what I can come up with, but I didn't= >> run into anything like this myself yet. >=20 > I locally forced a -dm on the ${MAKE} command involved > and the result reported: >=20 > Examining beforeinstall...non-existent....PHONY node...out-of-date. > recheck(beforeinstall): update time from 16:00:00 Dec 31, 1969 to now > Examining machine...modified 20:13:03 Nov 03, 2017...up-to-date. > Examining x86...modified 20:13:07 Nov 03, 2017...up-to-date. > Examining autoload.c...modified 2:27:17 Nov 03, 2016...up-to-date. > Examining autoload.o...modified 0:10:12 Nov 03, 2017...modified before= source x86...out-of-date. > cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/amd64_clang/= amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/us= r/src/amd64.amd64/tmp/usr/bin -O2 -pipe -ffreestanding -Wformat -mno-m= mx -mno-sse -mno-avx -msoft-float -fshort-wchar -mno-red-zone -mno-aes -D= LOADER_UFS_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MB= R_SUPPORT -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/libsa -I/usr/src/sys/= boot/zfs -DEFI_ZFS_BOOT -fPIC -DTERM_EMU -I/usr/src/sys/boot/efi/loader -= I/usr/src/sys/boot/efi/loader/arch/amd64 -I/usr/src/sys/boot/efi/include = -I/usr/src/sys/boot/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/i= nclude -I/usr/src/sys -I/usr/src/sys/boot/i386/libi386 -DNO_PCI -DEFI -DS= MBIOS_SERIAL_NUMBERS -I/usr/src/sys/boot/common -fPIC -I/usr/src/sys/boot= /ficl -I/usr/src/sys/boot/ficl/amd64 -I/usr/src/sys/boot/common -DBOOT_FO= RTH -DBF_DICTSIZE=3D15000 -g -std=3Dgnu99 -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototype= s -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum= -conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qun= used-arguments ERROR-tried-to-rebuild-during-make-install -c /usr/src/sy= s/boot/efi/loader/autoload.c -o autoload.o > /tmp/install.intsn5IS/sh: cc: not found > *** Error code 127 >=20 > So far I've not found anything with matching times for: >=20 > Examining machine...modified 20:13:03 Nov 03, 2017...up-to-date. > Examining x86...modified 20:13:07 Nov 03, 2017...up-to-date. >=20 > But the reason for rebuild is listed as: >=20 > modified before source x86...out-of-date. >=20 > I'll keep looking. The odd time (future) is in the > ball park of others from when the virtual machine > apparently had a bad time setting. >=20 > I'm not sure if the x86 is a file vs. a directory > here. A directory would seem a bit strange for > forcing a rebuild. (Similarly for machine.) It's these dependencies on a symlink: sys/boot/efi/boot1/Makefile:beforedepend ${OBJS}: x86 sys/boot/efi/loader/Makefile:beforedepend ${OBJS}: x86 A similar symlink is done for kernel modules but it avoids the problem you're hitting through various fixes such as in r72935 and r315459. I'll work on a fix. (It's unrelated to my recent changes) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --gH2GsuUNtt2oJg0voc1V9xcdpDwdJCvVs-- --cpHBcDaQVNXKcv8H5hLaoTSPt7QovStJR 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 iQEcBAEBAgAGBQJZ/MqgAAoJEDXXcbtuRpfPyWIH/24lgYdX+y0hnEqIlC4HE8Ib jC5AvvGjVuccU1+vlkUpygd0555Sa/SmOL+wDuVeMYwTOMO/tg4hq+bZhzVRjmJc sKeKHLSXhIrdbrIPV3HhNdkdozBqBe49HqD8hm9hN3JMwrl6XMjBlH83sZ+jIqQX BP05EwnOTrLfgFbKgbP1nqOrMCaj5YvLphUrx5GlOFpLG2VMdIy6o6ZzYQu+EjIp TR2w6CNcKlyoNVfe+gyIp3ntCxuCjHgNwtrtB+nLv+EJR3hjNRa5q92tU7lMez6M O99toYYM1RUrwC/0jS+17NGbUHIBFvOZSgL0/MrOxMqwiQ9abh+coAVuQkk+S8Q= =nYgb -----END PGP SIGNATURE----- --cpHBcDaQVNXKcv8H5hLaoTSPt7QovStJR-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 20:14:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C99BE5A646; Fri, 3 Nov 2017 20:14:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8AAA719E4; Fri, 3 Nov 2017 20:14:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 32C771084; Fri, 3 Nov 2017 20:14:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 677C7294F; Fri, 3 Nov 2017 20:14:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 5y_0oqwgkR1k; Fri, 3 Nov 2017 20:14:41 +0000 (UTC) Subject: Re: Head build unsafe for /etc today DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com CB85F294A To: Warner Losh , Steve Kargl Cc: Bryan Drewery , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Fri, 3 Nov 2017 13:14:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wiioQvcaKxm3suMQEJgeuwFrWB3r7dhgL" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:14:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wiioQvcaKxm3suMQEJgeuwFrWB3r7dhgL Content-Type: multipart/mixed; boundary="sMmqS4jPc55kdoMm9S01tPXebAqT1JCHe"; protected-headers="v1" From: Bryan Drewery To: Warner Losh , Steve Kargl Cc: Bryan Drewery , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Message-ID: Subject: Re: Head build unsafe for /etc today References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> In-Reply-To: --sMmqS4jPc55kdoMm9S01tPXebAqT1JCHe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/2017 8:58 PM, Warner Losh wrote: > FreeBSD has grown too big to test every possible thing before you commi= t. The build itself is massive. I usually forget about release/ and the new 'make packages', external toolchain, "old style" kernel builds, etc. Steve's concerns have validity. I do think it's time we have an automated suite to test most build cases for things like bmake upgrades or other high risk changes like META_MODE. I'll think about this and add to my list of things to implement. --=20 Regards, Bryan Drewery --sMmqS4jPc55kdoMm9S01tPXebAqT1JCHe-- --wiioQvcaKxm3suMQEJgeuwFrWB3r7dhgL 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 iQEcBAEBAgAGBQJZ/M4xAAoJEDXXcbtuRpfPnrcH+wZRI66SY7o81bAnAPteK3+q AaXZLVPL5cKhxAWKLwUQxap9BVXHA5FSMqvAS+bDdpolvgM/d0WhGhE9BR9Ge+KT BzFlfxmciq0iDtfx/xRNcDyl4DMkcweW97r4WKGiKyo+6pjoyfnvE8BF8SvWQ1CW i/B+3GuS+4wyy6IayuuQyOLKoIhIk74Fff5hygAepGJB07O/8bjOL2HNGSabKhUH QjyXA25KaMTwyfp5tRAtEeQFKHSV6cKJNRUXMG4tWfmQkuMhzYU63UO7Q/RBonJq Fec/ZYXBFwoHeyRMtz9uGkei947PMJV2C9MZKgU9p/CaTPZ+JUJ5XnLcH6h3mYI= =1sS2 -----END PGP SIGNATURE----- --wiioQvcaKxm3suMQEJgeuwFrWB3r7dhgL-- From owner-freebsd-hackers@freebsd.org Fri Nov 3 22:32:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD966E5CC76 for ; Fri, 3 Nov 2017 22:32:20 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8CE764DE for ; Fri, 3 Nov 2017 22:32:20 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: by mail-lf0-x241.google.com with SMTP id a132so4726525lfa.7 for ; Fri, 03 Nov 2017 15:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olevole-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KCuyPYI/6/B5Qs1j7Vn2rEgbtmm6DyDIKACDF/g/j/w=; b=AfJUKlfCpwrK0E2M0YgeVYnBoUeroZ6lrjFXX49F6CFSTvsiuQ17d6z5+xWhrzJxVu +vTIivadojJ/QZcgPw38oAXV6fLtOGDG2WD/YQkQWEbB3ZbWwbpTA0Nlvo8PEm4fam/L Xr6bRaYVOKG8Ui/b4gPwIUKDwHCeGkVdejLCO7RJVkqL7ajUwdui0lN5M3NUCcc1m99w uIImPXG3fD8OgeeUIA4HTE5Z5r61GjRgaDRRFI5aTOwE1RzKOYZWNjSw504Y+BPk6Dai VjBnRECu3n1eSU/vWavKNOGbc8Ny21CN6v0NwhyNUduoHN8ogrtNEaNqteN6OMXcF67p m3Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KCuyPYI/6/B5Qs1j7Vn2rEgbtmm6DyDIKACDF/g/j/w=; b=Ru6vPZHGy0FM9oF1NYytcaChr61yz5a16+EN/r0etO5LGOsYLQ880fjsyWqV1xW7cl yn0XyrcHfsynclo7LoHwg0yEiS9CZLUjR8Jikm19xJB3bI7gugdposJrEEhxeOJCeDXo XG2AJFJM+bpmpEWP3+VPzsfJFnlDOlI1C9YhelT0Db7QwiRZ00a5l0pFryG5Rh8RIRva jUWKjcoUqsGQHLlvKeOtHS5NOIXe4bmxwF9qFLOBUJB29bQ7SVQCM9hTn8H5FQYq3VTt KL+kNj2IW4XDBA6kC7q2gwILwwAQ8HuW8yLGhYTSsynx+IkjEMdlP5Rd0kzNK4G07lkM pLEg== X-Gm-Message-State: AJaThX58/IyT9ceibDXWzmSnki8tNr3AqqhktAdzpMFl62kE8uLQUVLE jsXGsfQnn2JJPgS2lU0bbw9WUf5NZJOAranrq8RGDcff X-Google-Smtp-Source: ABhQp+Q7XBi9f4QDVGe7GaEizpGKqlEzm2PQTNffw+EzCfUnrBhWTh2KiPWWxCvrM8NhS/GePHj3669PXbMnYVb4xXo= X-Received: by 10.25.163.196 with SMTP id m187mr3046844lfe.244.1509748337251; Fri, 03 Nov 2017 15:32:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.148.213 with HTTP; Fri, 3 Nov 2017 15:32:16 -0700 (PDT) X-Originating-IP: [95.28.195.106] From: Oleg Ginzburg Date: Fri, 3 Nov 2017 22:32:16 +0000 Message-ID: Subject: It will be nice to describe the incorrect behavior of RACCT To: freebsd-hackers@freebsd.org, trasz@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 22:32:20 -0000 Hello! It will be very nice if someone with a commit bit adds a few lines into racct(8) man page to the BUGS area a problem described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171811#c3 This will save a lot of time and nerves for those people who plan to use billing based on FreeBSD RACCT) From owner-freebsd-hackers@freebsd.org Sat Nov 4 15:23:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0215E4D572; Sat, 4 Nov 2017 15:23:41 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71C197235A; Sat, 4 Nov 2017 15:23:41 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.208] (cpe-23-242-94-236.socal.res.rr.com [23.242.94.236]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 4f19a509 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sat, 4 Nov 2017 08:23:37 -0700 (PDT) Subject: Re: Head build unsafe for /etc today To: Bryan Drewery , Warner Losh , Steve Kargl Cc: freebsd-hackers , FreeBSD Toolchain , FreeBSD Current References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> From: Pete Wright Message-ID: Date: Sat, 4 Nov 2017 08:23:38 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailman-Approved-At: Sat, 04 Nov 2017 17:33:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 15:23:41 -0000 On 11/03/2017 13:14, Bryan Drewery wrote: > On 11/2/2017 8:58 PM, Warner Losh wrote: >> FreeBSD has grown too big to test every possible thing before you commit. > The build itself is massive. I usually forget about release/ and the > new 'make packages', external toolchain, "old style" kernel builds, etc. > > Steve's concerns have validity. I do think it's time we have an > automated suite to test most build cases for things like bmake upgrades > or other high risk changes like META_MODE. > > > I'll think about this and add to my list of things to implement. > hey Bryan - this sounds like a pretty awesome task to take on, i'd be willing to help out with this effort as well.  if/when you come up with a plan would it be possible to ping freebsd-current@ so that i can see if there is anything i'll be able to help out with (assuming there isn't already a wiki or list somewhere i can reference to see where i may be able to chip in)? cheers! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-hackers@freebsd.org Sat Nov 4 17:23:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F148E50D83; Sat, 4 Nov 2017 17:23:20 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 3BD42767C3; Sat, 4 Nov 2017 17:23:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vA4HNABk001400; Sat, 4 Nov 2017 10:23:10 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vA4HNANJ001399; Sat, 4 Nov 2017 10:23:10 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201711041723.vA4HNANJ001399@pdx.rh.CN85.dnsmgr.net> Subject: Re: Head build unsafe for /etc today In-Reply-To: To: Bryan Drewery Date: Sat, 4 Nov 2017 10:23:10 -0700 (PDT) CC: Warner Losh , Steve Kargl , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 04 Nov 2017 22:45:53 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 17:23:20 -0000 > On 11/2/2017 8:58 PM, Warner Losh wrote: > > FreeBSD has grown too big to test every possible thing before you commit. I would say that it has always been too big to test every possible thing before a commit. Breakage is just going to happen, we make great efforts to minimize it, but like all risks sooner or later your gona have a failure. > > The build itself is massive. I usually forget about release/ and the > new 'make packages', external toolchain, "old style" kernel builds, etc. Good starting list for "make build-regresion" ? > > Steve's concerns have validity. I do think it's time we have an > automated suite to test most build cases for things like bmake upgrades > or other high risk changes like META_MODE. > > > I'll think about this and add to my list of things to implement. I would even go so far as to say this may be what we should be running in (a) Jenkins. Or perhaps a deeper exp-run? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Nov 4 22:51:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 738BDE58878; Sat, 4 Nov 2017 22:51:47 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23FF9177B; Sat, 4 Nov 2017 22:51:46 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id B7HseiVhX8LPZB7HuennbV; Sat, 04 Nov 2017 16:51:40 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=sC3jslCIGhcA:10 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=oVV4gydEhTvcyb8WQa0A:9 a=CjuIK1q_8ugA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 63A871040; Sat, 4 Nov 2017 15:51:36 -0700 (PDT) Received: from slippy (localhost [IPv6:0:0:0:0:0:0:0:1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id vA4MpZs8061361; Sat, 4 Nov 2017 15:51:35 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201711042251.vA4MpZs8061361@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Rodney W. Grimes" cc: Bryan Drewery , Warner Losh , Steve Kargl , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Subject: Re: Head build unsafe for /etc today In-Reply-To: Message from "Rodney W. Grimes" of "Sat, 04 Nov 2017 10:23:10 -0700." <201711041723.vA4HNANJ001399@pdx.rh.CN85.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Nov 2017 15:51:35 -0700 X-CMAE-Envelope: MS4wfLPq7Njx1rohygjBq57WKfVO1lJ9Sd2UQWVkgNQAYNocjY06JoRDMyFY7qH2bVk9c0AECpwAVX23iNZnzs8qofQJMXndA/5YjijP+v2bY/1dVZtKcqz+ mOVRhUu9WD7IvpwBW6Nor65jWQHONYEdLx6nfxf+ESXEK1oa4izjErUMo9DO2BmiGlfnq77xCqB8i5wD+gQ42ehtnbxUkOy5sA7sIR0bE+ahzhUUYBODDVxl qdKfgZHzfHDnMAnvB8pSALgDEs9Ev10xxw7rmCONEEfSBTCSU8N13xajwl+YVItGeO1jusX1N5liNRG4+FdHt1Q7MmMg1wbvHFZs99QXax8gScs/eFx9uSJd MVMrV+JOSl0JnhDOCoFe3J7FqXV5fZdcNOqTE/1dBynOM2QQRuOqK53eI7OT5jkJE4fbAv8P X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 22:51:47 -0000 In message <201711041723.vA4HNANJ001399@pdx.rh.CN85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > On 11/2/2017 8:58 PM, Warner Losh wrote: > > > FreeBSD has grown too big to test every possible thing before you commit. > > I would say that it has always been too big to test every possible > thing before a commit. Breakage is just going to happen, we make > great efforts to minimize it, but like all risks sooner or later > your gona have a failure. > > > > > The build itself is massive. I usually forget about release/ and the > > new 'make packages', external toolchain, "old style" kernel builds, etc. > Good starting list for "make build-regresion" ? > > > > > Steve's concerns have validity. I do think it's time we have an > > automated suite to test most build cases for things like bmake upgrades > > or other high risk changes like META_MODE. > > > > > > I'll think about this and add to my list of things to implement. > > I would even go so far as to say this may be what we should be > running in (a) Jenkins. Or perhaps a deeper exp-run? Yes. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.