From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 11:09:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA0D6A89 for ; Sun, 17 May 2015 11:09:04 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.198]) (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 0D89A1225 for ; Sun, 17 May 2015 11:09:02 +0000 (UTC) Received: (qmail 6377 invoked from network); 17 May 2015 11:02:18 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 17 May 2015 11:02:18 -0000 Message-ID: <5558752E.8030404@erdgeist.org> Date: Sun, 17 May 2015 13:02:06 +0200 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: lam silently spills overly long lines Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 11:09:04 -0000 Dear all, when working on a set of files quite large files I noticed that lam(1) would suddenly start combining lines that clearly don't belong together. I tracked it down to a single overly long line (with overly meaning > BUFSIZ from stdio.h) in one of the files and noticed that in https://svnweb.freebsd.org/base/head/usr.bin/lam/lam.c?revision=227240&view=markup#l201 the function gatherline would not consume all chars up to the eol marker for that file, leaving the reminder of that particular input line fragment for the next output line, in turn screwing up the output. I find that behaviour surprising and would expect a) lam not to choke on lines over an arbitrary size limit or b) try to get itself in a consistent state in this easily to understand situation and/or c) exit or at least issue a warning while doing something unexpected. I finally switched to using the paste(1) tool where this problem does not occur but still found the issue annoying enough to send this email. I also offer to write the patch. erdgeist From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 22:43:48 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E716B596 for ; Sun, 17 May 2015 22:43:48 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 713201852 for ; Sun, 17 May 2015 22:43:48 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t4HMha8Z071930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 18 May 2015 00:43:37 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t4HMheDA001026 for ; Mon, 18 May 2015 00:43:40 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t4HMhYwi001023 for ; Mon, 18 May 2015 00:43:35 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Mon, 18 May 2015 00:43:34 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: Got seagate archive Was: Help with 8TB Seagate Archive In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 18 May 2015 00:43:37 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 22:43:49 -0000 For others interested i have this drive running in backup server now. it's used with GEOM_ELI and UFS. What about performance: Excellent on reads. Tolerable on writes as long as you will not write more than 10-15GB in a short time, then it REALLY slows down. This "hardware managed" SMR drive puts all random writes in it's log which takes AFAIK 20GB of reserved space. When disk is idle or log is full, it performs real writes/rewrites to SMR chunks which is slow. >From my observation it do it in batches resulting in half a minute or so stalls. Stalls include reads. Overall write performance is tolerable still. Now i am in process of copying 3TB of data from other disk. Then it will be used as usual with running rsync once per day. Usually there are less than 20GB data transferred per day to one disk so it should consistently keep good performance. Overall i do recommend this drive to any use that does not require heavy random write I/O including: - backup server - read-mostly data storage. - very large file storage, with properly tuned filesystem (64kB blocks, maybe even more after modifying kernel). Finally, contrary to what i read, it is not 4KB native, but 4K emulated. smartctl reports 4KB physical and 512B logical sectors. Of course make sure you use 4kB alignment, 4kB GELI blocks, and at least 4kB UFS fragments. it's really cheap for it's size, silent and low power. But it would be nicer if stalls on log full would not include reads. No opinion for ZFS users, i don't use, nor plan to use ZFS anywhere. From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 07:53:26 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01990810 for ; Mon, 18 May 2015 07:53:25 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::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 B04151E8A for ; Mon, 18 May 2015 07:53:25 +0000 (UTC) Received: by qcir1 with SMTP id r1so19183127qci.3 for ; Mon, 18 May 2015 00:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WwZw6hZRk3x8OlnAI4i6PIT7YAFeuHUccLlVnB+2dfo=; b=FoSPXkOYUhgT1CsPUf/BVbN95hXHeC4mFGlXFUpzULy4Gv5Ftc9QMEN4EVJOkdMAdz Df84Te7dshkN0izjmX9l3ChGWMKYmH4GtOK1qS4jfL+dU+xPcho99zKy/1E6oP54pDNh PXmtwJYxfATpM2TBsvw7rqPPxV/vD1TA36EcMQIjJviYMXwjNxdO47d/Bs7fzdYLSFjp JbdOD07VWRz+ncIa37nrz5mHoOJ+Y4ufLgU482euXkhL9gDuJ54uaXm4MRVQ1zQXIb89 y2FfE65W3NPxReRjfmKrEbKw8VFq0RFKbNLbXhoCHVldT5x8RBk1Pu6K31Jd1Cm2/g7T kPCg== X-Received: by 10.140.134.145 with SMTP id 139mr28803774qhg.6.1431935604820; Mon, 18 May 2015 00:53:24 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.140.102.194 with HTTP; Mon, 18 May 2015 00:52:44 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Mon, 18 May 2015 08:52:44 +0100 X-Google-Sender-Auth: wEcRpSUvblDEG5aPUAP8u6whDOs Message-ID: Subject: Re: Got seagate archive Was: Help with 8TB Seagate Archive To: Wojciech Puchar Cc: Hackers freeBSD Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 07:53:26 -0000 On 17 May 2015 at 23:43, Wojciech Puchar wrote: > For others interested i have this drive running in backup server now. it's > used with GEOM_ELI and UFS. > > What about performance: > > Excellent on reads. Tolerable on writes as long as you will not write more > than 10-15GB in a short time, then it REALLY slows down. > What sort of performance do you get when you use the drive as intended (i. e. tape-on-disk), either using tar or dd to raw device, i. e. where the writes are always linear and not scattered? -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 16:27:13 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9781EA2 for ; Mon, 18 May 2015 16:27:13 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 521321F7C for ; Mon, 18 May 2015 16:27:12 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t4IGR7eF015603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 May 2015 18:27:07 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t4IGRA4c000707; Mon, 18 May 2015 18:27:10 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t4IGR4df000704; Mon, 18 May 2015 18:27:05 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Mon, 18 May 2015 18:27:04 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Igor Mozolevsky cc: Hackers freeBSD Subject: Re: Got seagate archive Was: Help with 8TB Seagate Archive In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 18 May 2015 18:27:08 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:27:13 -0000 > slows down. > > > > What sort of performance do you get when you use the drive as intended (i. e. tape-on-disk), either using tar or dd to raw device, > i. e. where the writes are always linear and not scattered? not tested purely linear writes, but writing large files result in slowdowns too. maybe smaller. Ask someone to test speed with dd if=/dev/zero of=/dev/seagate-archive bs=1m and check speed AFTER 20-30GB got written. in theory it should be fast. in theory there is no difference between theory and practice. In practice it is ;) Actually it should be OK if firmware is well written. In my opinion it is usable but not really well written. From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 16:48:00 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD02ADF4 for ; Mon, 18 May 2015 16:48:00 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 A8D1812B6 for ; Mon, 18 May 2015 16:48:00 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so53672836igb.0 for ; Mon, 18 May 2015 09:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=xsnseXq4LYbzZUuaGlhq6UL2dhz/cP4+9lBgjipz0EM=; b=eNsyHiT33jRccBqWHgnNhJXgn/pqS3226nJpyPrFCMM0EHvHqFi3Hb489BXi2gUvMg ofzYlanEd3Fgq8Gi47a9PyhQUDpc1HkX3qyHzCz+d/36BbGsSfzJu4vasbuiCdXWfS7M dZMdPPwa1c9NFd4k/cMNYCdlGZsHe+eu9CywD+yinBTCwGW32a/MbafmjmH9v2lcPMGq NZqe0YQmiWRZq4C+eFnHJE2ebX720ALfYelbR987hVbPa5gF5yyhCHAE6rUMZiSmxclp BCI2L+rzWsMaBGAPFCfsXLpjDBS0V5nkFUo5Po16ZHH/zbhHoPhmS/Y4DsCsD1/UPlBV jZvw== X-Received: by 10.50.33.51 with SMTP id o19mr15760800igi.45.1431967680141; Mon, 18 May 2015 09:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.136.35 with HTTP; Mon, 18 May 2015 09:47:29 -0700 (PDT) From: Gleb Popov <6yearold@gmail.com> Date: Mon, 18 May 2015 19:47:29 +0300 Message-ID: Subject: Strange manual pages at freebsd.org/cgi/man.cgi To: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:48:01 -0000 Hello. I've stumbled upon this manual page [1], but where mut.h comes from. I take it is provided by some port, since `man naturalstrcmp` yields nothing in fresh FreeBSD install. [1] https://www.freebsd.org/cgi/man.cgi?query=naturalstrcmp&sektion=3&manpath=FreeBSD+10.1-RELEASE+and+Ports From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 19:28:35 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9038F21A for ; Mon, 18 May 2015 19:28:35 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 3CFEC18B3 for ; Mon, 18 May 2015 19:28:35 +0000 (UTC) Received: by wichy4 with SMTP id hy4so135368wic.1 for ; Mon, 18 May 2015 12:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tv8f1wEDWhoc3NhE+sbzQoLIs1AylvAHPgS+1cPfnm4=; b=RHvWfks5h40Yv2cLWPguX/G0rFLMSCzUuJGnwg1FQCxRE45oTk69irWv7UaWG0Gc1X /YQYwaKnCW8C2v+/HPEkEJUKbwgQhc1iziC00a4wCnDeXl8F1Io6rqr7ZI0OmK6sB7d6 JettC1ek36DyzwHOBrGXQ8OrKIOyuIA4c+FeAINS2P5LrPutoK9Ne4X2Brl7+HXQK0vH 2sAjTHUj2q8LClgoOCv/atv9Sv5kqUYwwiK4tTx99+HeQ8h4x2uS9DWcxO9gEj4o9LV/ KOEDG7XHpR++AxmHOAxEh0lV4FX3ilc6lzuPGpLzw2dpiDOvQ5nog9QgOnFeW3sqOHVs c2lg== MIME-Version: 1.0 X-Received: by 10.194.179.67 with SMTP id de3mr18631069wjc.77.1431977313772; Mon, 18 May 2015 12:28:33 -0700 (PDT) Received: by 10.27.100.214 with HTTP; Mon, 18 May 2015 12:28:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 May 2015 22:28:33 +0300 Message-ID: Subject: Re: Strange manual pages at freebsd.org/cgi/man.cgi From: Sergey Kandaurov To: Gleb Popov <6yearold@gmail.com> Cc: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 19:28:35 -0000 On 18 May 2015 at 19:47, Gleb Popov <6yearold@gmail.com> wrote: > Hello. > > I've stumbled upon this manual page [1], but where mut.h comes from. I take > it is provided by some port, since `man naturalstrcmp` yields nothing in > fresh FreeBSD install. > > [1] > https://www.freebsd.org/cgi/man.cgi?query=naturalstrcmp&sektion=3&manpath=FreeBSD+10.1-RELEASE+and+Ports You may want to check this service: http://manned.org/naturalstrcmp -> cad/alliance -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 20:48:56 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E79AB56 for ; Mon, 18 May 2015 20:48:56 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 5D85E12BB for ; Mon, 18 May 2015 20:48:56 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so59351936igb.1 for ; Mon, 18 May 2015 13:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dbg3UiPyZeidzdzfnjTl3JDhBxAs9xrUJHP0/JvboCU=; b=Fqe2AviAX4r/rQVwBHR1Y4N7E/ZaXkVUe3tbpTcTPEnSXp8Bt/3nuWwdjemD8da9Y2 E4jpaVn1rNBuHo7EocSaAnxwA07dcGY6AdQve4rce8TjZ2fByNqaMuZzFpTuc+LV4GJj ip/ykHcW/QStU5YO4K0oSEfHNmUXn25T+0Jpc00XC9BwhT6BAoJU7v4U1cz3MsgBKRkl 3P5qurzJjqnfT4f0ep6h6ZBDXWGZmpAulpvc5SI3uHkowoHbkrujC+DvJp5TAeujgUyO zRzhv8rOwc9G+jjPAAY8vGwZ/8lqKlnRoPipzzy3AgV4TomnHEiI7vT/E3DBqSflre5j 9OzQ== X-Received: by 10.42.164.7 with SMTP id e7mr36540143icy.70.1431982135830; Mon, 18 May 2015 13:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.136.35 with HTTP; Mon, 18 May 2015 13:48:25 -0700 (PDT) In-Reply-To: References: From: Gleb Popov <6yearold@gmail.com> Date: Mon, 18 May 2015 23:48:25 +0300 Message-ID: Subject: Re: Strange manual pages at freebsd.org/cgi/man.cgi To: Sergey Kandaurov Cc: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 20:48:56 -0000 On Mon, May 18, 2015 at 10:28 PM, Sergey Kandaurov wrote: > On 18 May 2015 at 19:47, Gleb Popov <6yearold@gmail.com> wrote: > > Hello. > > > > I've stumbled upon this manual page [1], but where mut.h comes from. I > take > > it is provided by some port, since `man naturalstrcmp` yields nothing in > > fresh FreeBSD install. > > > > [1] > > > https://www.freebsd.org/cgi/man.cgi?query=naturalstrcmp&sektion=3&manpath=FreeBSD+10.1-RELEASE+and+Ports > > You may want to check this service: > http://manned.org/naturalstrcmp -> cad/alliance > Wow, what a handy site. Thanks for the link! > > -- > wbr, > pluknet > From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 22:44:21 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3755EF78 for ; Mon, 18 May 2015 22:44:21 +0000 (UTC) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 E8C1C103A for ; Mon, 18 May 2015 22:44:20 +0000 (UTC) Received: by qkgw4 with SMTP id w4so79154746qkg.3 for ; Mon, 18 May 2015 15:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FzYDgvui1fzJHPGldnJSitYhVu7NKo3zBKuBmy90Mfk=; b=hlL0sKaFlO/h7xYenGcUnUlPrfeRGm8aEK0bpWF99IJiTY3D0nEtguNW14mAFV42So r1yRcs0xGdQeb8L2dT10QfeTTGY9HSuSARm5hMhfMOQO3t+DdA0m+9yPdglIVR1OQLF7 XUfG+3IqUYxftygRp291ibPk8ROr01LCu2XDb0xvwdfZcauvdU7ERWR6Jz/KqB8WXnoA TxxuSfV00CmUq4L3m/2K+3UkpXVmeraIJ14loe7Netor42uQLiMJ50jhO/hE1q8rUz0K n+PyMVJCZFKzTid29ubLkcfoCV99RTJuF8A2gDUpAaoe+MTzblc3TFvSWU94cDPAt8Nm 2JTw== MIME-Version: 1.0 X-Received: by 10.55.51.129 with SMTP id z123mr51968828qkz.102.1431989059863; Mon, 18 May 2015 15:44:19 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Mon, 18 May 2015 15:44:19 -0700 (PDT) In-Reply-To: <20150509190347.10e1e2c2@kan> References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> Date: Mon, 18 May 2015 15:44:19 -0700 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: NGie Cooper To: Alexander Kabaev Cc: Sean Bruno , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:44:21 -0000 On Sat, May 9, 2015 at 4:03 PM, Alexander Kabaev wrote: > On Sat, 09 May 2015 11:30:59 -0700 > Sean Bruno wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 05/09/15 11:09, Jeff Meegan wrote: >> > You could try -O0, but also if you just care about txr, go up to >> > frame 12 where txr initialized to the context arg to em_handle_tx() >> > and print it out there. >> > >> > -j >> >> I'm guessing that the place to change -O2 -> -O0 is in kern.pre.mk ? >> >> sean > > No, it means you need to iescover DEBUG and how it affects optimization > level :) > > .if defined(DEBUG) > _MINUS_O= -O > CTFFLAGS+= -g > .else > ... > > Say, I have 'makeoptions DEBUG="-g -gdwarf-2"' in my kernel config > file. -gdwarf-2 is probably not required anymore. This isn't working as advertised. While trying to track down issues with clang at $work with variables that were optimized out, I noticed that it was passing through -O2 explicitly, even though DEBUG=-g was defined in our KERNCONF, which is supposed to set _MINUS_O to -O. I did some more poking around and it appears to always be the case with 11-CURRENT as well (see below). I'll post a diff for kern.pre.mk that fixes this on Phabricator soon, because this is breaking our debuggability of clang kernels. Thanks, -NGie $ git diff sys/conf/kern.pre.mk diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index 8c3b9c6..2ab0647 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -102,6 +102,8 @@ CFLAGS.gcc+=${CFLAGS_ARCH_PARAMS} .endif WERROR?= -Werror +.error "CFLAGS: ${CFLAGS}" + # XXX LOCORE means "don't declare C stuff" not "for locore.s". ASM_CFLAGS= -x assembler-with-cpp -DLOCORE ${CFLAGS} ${ASM_CFLAGS.${.IMPSRC:T}} $ script ts make buildkernel KERNCONF=GENERIC KERNCONFDIR=/sys/amd64/conf/ SRCCONF=/dev/null __MAKE_CONF=/dev/null -j12 Script started, output file is ts --- buildkernel --- --- buildkernel --- -------------------------------------------------------------- >>> Kernel build for GENERIC started on Mon May 18 15:38:04 PDT 2015 -------------------------------------------------------------- ===> GENERIC mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/GENERIC -I '/sys/amd64/conf/' '/sys/amd64/conf//GENERIC' Kernel build directory is /usr/obj/usr/src/sys/GENERIC Don't forget to do ``make cleandepend && make depend'' -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 11.0-CURRENT amd64 1100073" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" make -j 12 -J 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir make[2]: "/usr/src/sys/conf/kern.pre.mk" line 105: "CFLAGS: -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h" >From /usr/obj/usr/src/sys/GENERIC/Makefile: 1 KERN_IDENT=GENERIC 2 MACHINE=amd64 3 MACHINE_ARCH=amd64 4 WITH_CTF=1 5 DEBUG=-g 6 S=/usr/src/sys From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 00:29:51 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA560306 for ; Tue, 19 May 2015 00:29:51 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 A4C371B15 for ; Tue, 19 May 2015 00:29:51 +0000 (UTC) Received: by qgfa7 with SMTP id a7so43714170qgf.1 for ; Mon, 18 May 2015 17:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J+bn0/Gyg5FXPXLF3IeyE05rbfv/ujWiPSyx7/uwGdI=; b=KzXCE1CFtl8da/OmsFO+HRc260m3tWG9pEqv85JFJeyCEeJL6J3Ed8C1QG6W9ho++Z K+v0hQTWZ52Ekqj4bsf9iL9yT9XNazqlgAx1xg0BCZJ+Easa49BuxwKiM0FIz+2NaJf4 J7igcVplwR9yxPSpzjIj6+Ed1ByadcSKv8GXQJxexiXHtX0S0w2txm8F6LqaaGVxnzM9 dZHoaf66kSug1b5uMe6smMYXqpoF0I6WEbhVsuZJPQxsr3IZcjo1aM+R3aC/Ge/ftf6h 5IROC/DzloLRFZ/3HIIqWAJWLrIjSM1eJF0M3XALwaCWCYnWGDBgAwJv9Q2Mb13grGFj Zorg== MIME-Version: 1.0 X-Received: by 10.55.51.129 with SMTP id z123mr52664475qkz.102.1431995390769; Mon, 18 May 2015 17:29:50 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Mon, 18 May 2015 17:29:50 -0700 (PDT) In-Reply-To: References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> Date: Mon, 18 May 2015 17:29:50 -0700 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: NGie Cooper To: Alexander Kabaev Cc: Sean Bruno , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 00:29:52 -0000 On Mon, May 18, 2015 at 3:44 PM, NGie Cooper wrote: ... > This isn't working as advertised. > > While trying to track down issues with clang at $work with variables > that were optimized out, I noticed that it was passing through -O2 > explicitly, even though DEBUG=-g was defined in our KERNCONF, which is > supposed to set _MINUS_O to -O. > > I did some more poking around and it appears to always be the case > with 11-CURRENT as well (see below). > > I'll post a diff for kern.pre.mk that fixes this on Phabricator soon, > because this is breaking our debuggability of clang kernels. > > Thanks, > -NGie > > $ git diff sys/conf/kern.pre.mk > diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk > index 8c3b9c6..2ab0647 100644 > --- a/sys/conf/kern.pre.mk > +++ b/sys/conf/kern.pre.mk > @@ -102,6 +102,8 @@ CFLAGS.gcc+=${CFLAGS_ARCH_PARAMS} > .endif > WERROR?= -Werror > > +.error "CFLAGS: ${CFLAGS}" > + > # XXX LOCORE means "don't declare C stuff" not "for locore.s". > ASM_CFLAGS= -x assembler-with-cpp -DLOCORE ${CFLAGS} ${ASM_CFLAGS.${.IMPSRC:T}} > > $ script ts make buildkernel KERNCONF=GENERIC > KERNCONFDIR=/sys/amd64/conf/ SRCCONF=/dev/null __MAKE_CONF=/dev/null > -j12 > Script started, output file is ts > --- buildkernel --- > --- buildkernel --- > -------------------------------------------------------------- >>>> Kernel build for GENERIC started on Mon May 18 15:38:04 PDT 2015 > -------------------------------------------------------------- > ===> GENERIC > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/GENERIC -I '/sys/amd64/conf/' > '/sys/amd64/conf//GENERIC' > Kernel build directory is /usr/obj/usr/src/sys/GENERIC > Don't forget to do ``make cleandepend && make depend'' > -------------------------------------------------------------- >>>> stage 2.1: cleaning up the object tree > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD > 11.0-CURRENT amd64 1100073" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp " AS="as" AR="ar" LD="ld" > NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= > SIZE="size" make -j 12 -J 15,16 -m /usr/src/share/mk KERNEL=kernel > cleandir > make[2]: "/usr/src/sys/conf/kern.pre.mk" line 105: "CFLAGS: -O2 -pipe > -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h" > > From /usr/obj/usr/src/sys/GENERIC/Makefile: > > 1 KERN_IDENT=GENERIC > 2 MACHINE=amd64 > 3 MACHINE_ARCH=amd64 > 4 WITH_CTF=1 > 5 DEBUG=-g > 6 S=/usr/src/sys As a sidenote, this has been broken for over a decade: https://svnweb.freebsd.org/base?view=revision&revision=127204 :(... From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 11:19:52 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBBA3CF5 for ; Tue, 19 May 2015 11:19:52 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD8E1AC5 for ; Tue, 19 May 2015 11:19:50 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t4JBJHpZ085000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 May 2015 21:19:25 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t4JBJC0u045292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 May 2015 21:19:12 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t4JBIv3n045291; Tue, 19 May 2015 21:18:57 +1000 (AEST) (envelope-from peter) Date: Tue, 19 May 2015 21:18:57 +1000 From: Peter Jeremy To: Dirk Engling Cc: freebsd-hackers@freebsd.org Subject: Re: lam silently spills overly long lines Message-ID: <20150519111857.GD78998@server.rulingia.com> References: <5558752E.8030404@erdgeist.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <5558752E.8030404@erdgeist.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 11:19:52 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-May-17 13:02:06 +0200, Dirk Engling wrote: >when working on a set of files quite large files I noticed that lam(1) >would suddenly start combining lines that clearly don't belong together. > >I tracked it down to a single overly long line (with overly meaning > >BUFSIZ from stdio.h) in one of the files and noticed that in I think a lot of Unix utilities assume that input lines will not exceed BUFSIZ and silently split longer lines. This is usually "good enough" so fixing it often isn't a high priority. >I also offer to write the patch. That would be wonderful. If you do so, please attach it to a bugzilla PR (and maybe copy the PR number into this thread). --=20 Peter Jeremy --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVWxwhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs01r8P/2QV8TYzVGhmfHghY38iCC9D xOeVZDGi2tGv69N65dGDQhWPvfb0LKWbCmrMcCz0um76A5FTmsAPKXELvScv9zr3 NHf4RxHEOgxXZ0y6eyFrb2PMk5cHk7QLYQOM/152RI+r3OkXXTLNBGI5lazEQ0tE sJgDwxFikQG5zeHErOgri3+YqoFyI4+Iqxyi6Xqct7St4fpVvdlNdSqrLsnQ0rpv AcM6lc+CAJt+USQrsjvQur3LOM3yavWCARyy85zvWjIgSDjSq/UxK0WFPhcg2k4s HYGHzHaw24/peJzow1ordIJGhYptR5+ICZWlvaWwH1rkTZuAHVu/FZoeejRe/QgW R8FG3SI20hS+fKIDfstC1j5usF1Eb5s0FDfAvoefMlREWKPpV7g9jz7mEhuJG9v8 boSwr+jYHIPRHNMTI4S/HqCJtm7BN2Iu403g8FoIitnHArV2Qe8C50MGYdgUJDt2 NSZVgHddAKpIvxWidLNni+GLSc3LJhTYfP8G5kNxjEms1D5scCRNjIy+K5NwJKJV QnLdIHD9MmIn3gyWUGpNIQzqv5iRolwnqGLssjXZYvbJpqvWDNtSBE2Loce1GFbg V8KAStcMHqLj0amrCc1vXT+s7f6yJJjcWnuYAzLJrY5+rPyA8/FHFZw3K9yiF9gq 8K/Q9g13mEEXw45Qpp60 =rKlN -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 16:23:50 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D343AA for ; Tue, 19 May 2015 16:23:50 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 217671356 for ; Tue, 19 May 2015 16:23:49 +0000 (UTC) Received: from [192.168.1.128] (wsip-98-172-74-163.ph.ph.cox.net [98.172.74.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 5F997193656 for ; Tue, 19 May 2015 16:23:43 +0000 (UTC) Message-ID: <555B638E.4020405@ignoranthack.me> Date: Tue, 19 May 2015 09:23:42 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Trying to use clang/head and XCC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:23:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Following the External Tool Chain instructions on the wiki seem to not work: https://wiki.freebsd.org/ExternalToolchain I've gotten about this far: https://people.freebsd.org/~sbruno/clang_head_build_log.txt Two items of note. -- The bootstrap bits *completely* ignore XCC and build with the host cc/c++ -- No documentation of what CFLAGS are required to build and ignore warnings. Anyone out there have success doing this? sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVW2OLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k3mQIAKuOxH8h1AdG19pVCks2N91i u50m/EWqyhOqJtW9PzHgFhmph8dtzZQVXbh3JG2Ac8bQjHdvuFP4yG5PJKISK3ZQ 2JhD+8B2qrJlv6kocE39WiSEXZRf6nQkbrh/DNzRN0tDHPtxsJ6vfN7j5oWap32j ZKVMq4I61zmACN/trb/8Ns2bmwRKd003F5vmytx4FG1vA3Q14l/URvcBmFstPGDq nmcvMf2oU190R2XQEwuqmkTGouaIkJ1j28x4/I4lH+tLKPKkErklpZxxm+jf+QQd j++8+zoiEQVYrEPKEoc5xd1V393vvt5+kc7Kqo2kqJrK4+EjsLpSQMuQ9tDgQRU= =wYq7 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 16:53:40 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 574A2A5E; Tue, 19 May 2015 16:53:40 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3519C1726; Tue, 19 May 2015 16:53:39 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id DE6C05A9F25; Tue, 19 May 2015 16:53:32 +0000 (UTC) Date: Tue, 19 May 2015 16:53:32 +0000 From: Brooks Davis To: sbruno@freebsd.org Cc: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC Message-ID: <20150519165332.GA36377@spindle.one-eyed-alien.net> References: <555B638E.4020405@ignoranthack.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <555B638E.4020405@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:53:40 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Following the External Tool Chain instructions on the wiki seem to not > work: > https://wiki.freebsd.org/ExternalToolchain >=20 > I've gotten about this far: > https://people.freebsd.org/~sbruno/clang_head_build_log.txt You need to delete /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* and possibly also limits.h (it's broken for libstand on mips). If you use the ports/pkgs they do this. > Two items of note. > -- The bootstrap bits *completely* ignore XCC and build with the host > cc/c++ That's expected. In principle clang could be used as the cross compiler since it's multi-target, but gcc could never work unless the host and target are the same. > -- No documentation of what CFLAGS are required to build and ignore > warnings. It will change with every clang/gcc release. In practice you will need to either fix the warnings wack-a-mole style or set NO_WERROR in the environment. -- Brooks >=20 > Anyone out there have success doing this? >=20 > sean > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQF8BAEBCgBmBQJVW2OLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k3mQIAKuOxH8h1AdG19pVCks2N91i > u50m/EWqyhOqJtW9PzHgFhmph8dtzZQVXbh3JG2Ac8bQjHdvuFP4yG5PJKISK3ZQ > 2JhD+8B2qrJlv6kocE39WiSEXZRf6nQkbrh/DNzRN0tDHPtxsJ6vfN7j5oWap32j > ZKVMq4I61zmACN/trb/8Ns2bmwRKd003F5vmytx4FG1vA3Q14l/URvcBmFstPGDq > nmcvMf2oU190R2XQEwuqmkTGouaIkJ1j28x4/I4lH+tLKPKkErklpZxxm+jf+QQd > j++8+zoiEQVYrEPKEoc5xd1V393vvt5+kc7Kqo2kqJrK4+EjsLpSQMuQ9tDgQRU=3D > =3DwYq7 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >=20 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVW2qLAAoJEKzQXbSebgfAxbMH/jI7ia+dO/b4uaxHmVe1rZLf uPXkv8N4gG8ShJL262F9SOmyqPFOCEl0+VwN+3ICthKCOFhv5RXcOEdpEoLKO//B H/SN2xAFVhYPb7qhI0I4ORJ+z43CejD0vHcloawz3QeTSpMQY4bgFZy2ZZYbOoat 0L4mHzNbQLlPnsHiCvd7CH9KeHHdwn3+WqJO1c/DU59ZCuwkDzS2urAWzRuHeUA5 cpRtS4TMBp5RnCZsznziaEQzYPHwjKApUXzh5vE8Gk1rYgDMIA5p2jxY1ksND1S4 M5mmd5HpT4VLxuVthMNFJiTqF6SptS3mwsXAxfGUK5acvXiFMQyTDjOfu6pstVU= =0GjU -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 19:06:18 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84E85C24; Tue, 19 May 2015 19:06:18 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 552B81793; Tue, 19 May 2015 19:06:18 +0000 (UTC) Received: by pdbnk13 with SMTP id nk13so37115666pdb.1; Tue, 19 May 2015 12:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to; bh=yGbyuNZZcnf+WqeDSNoKEuU5clC7x6WaNZ61xKbdgOw=; b=k9d4AQhPYANksJpEFysbc9VgWRSfAG0IzPbShGRCgO0w23k9DL8j8BfA9L2+fu+seL Ct1MfDEGPaQ6W5C+k/empuDVRUrV/a+qAmovcvhNyi/x+AWalXGJ6xbvqEZP8iwJNxl1 dbIEjU4nHd73X74EdeBe0wYwmFWl2SuoFLJ6PGtFpRp9/w8aytvJ/1rDD9pgJfG23eGo rXcc9GzZou8c1nqd5CKBpI6l4k2rPzJ3GoSKn8JVSNBcnYTXrUt+YJ+Jt4xG5b/0r5Vh UVDSVDzIdFJCDc5fFuUkuQk1izoJZdCVILJAEAe6Bh9ypiVPwdaDfW6Mn0/1gPqiYGj5 duGw== X-Received: by 10.69.17.68 with SMTP id gc4mr56108098pbd.7.1432062377847; Tue, 19 May 2015 12:06:17 -0700 (PDT) Received: from [192.168.242.55] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id nl16sm13812775pdb.56.2015.05.19.12.06.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 May 2015 12:06:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> From: Garrett Cooper Mime-Version: 1.0 (1.0) In-Reply-To: <20150519165332.GA36377@spindle.one-eyed-alien.net> Message-Id: <168384B2-A313-4D10-8E5C-2A7A7FC807B7@gmail.com> Date: Tue, 19 May 2015 11:55:08 -0700 Cc: "sbruno@freebsd.org" , "freebsd-hackers@freebsd.org" To: Brooks Davis X-Mailer: iPhone Mail (12F70) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:06:18 -0000 > On May 19, 2015, at 09:53, Brooks Davis wrote: >=20 >> On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Following the External Tool Chain instructions on the wiki seem to not >> work: >> https://wiki.freebsd.org/ExternalToolchain >>=20 >> I've gotten about this far: >> https://people.freebsd.org/~sbruno/clang_head_build_log.txt >=20 > You need to delete > /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* and > possibly also limits.h (it's broken for libstand on mips). If you use > the ports/pkgs they do this. >=20 >> Two items of note. >> -- The bootstrap bits *completely* ignore XCC and build with the host >> cc/c++ >=20 > That's expected. In principle clang could be used as the cross compiler > since it's multi-target, but gcc could never work unless the host and > target are the same. >=20 >> -- No documentation of what CFLAGS are required to build and ignore >> warnings. >=20 > It will change with every clang/gcc release. In practice you will need > to either fix the warnings wack-a-mole style or set NO_WERROR in the > environment. >=20 > -- Brooks >=20 >>=20 >> Anyone out there have success doing this? It'd be really nice if FreeBSD had HOST_CC, etc or something like that. It's= unfortunate that I can't build 10.x on hosts with clang 3.6 installed becau= se it fails to make bootstrap-tools (which needs to be built with the host c= ompiler) because of -Werror ;(... Thanks, -NGie= From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 19:32:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90C81DA7 for ; Tue, 19 May 2015 19:32:39 +0000 (UTC) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 4ABA71B88 for ; Tue, 19 May 2015 19:32:39 +0000 (UTC) Received: by qkdn188 with SMTP id n188so12406696qkd.2 for ; Tue, 19 May 2015 12:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8nKC/azG2vitKFlCEw4lXUCYfRUBjYRm394zgHn1Hoc=; b=mEqtOnuBM/GGJaZXJdYSFejKdGEVJeo4wi7a0PmQ5MMa0Mwpo33rJlM6UCzIYxM6l4 Vzhv84bWwPKOsX+89BjRhKhWOqMcRa2PuNZ6BNUXsYclMUDSdlIF0TavOhn44e7q+3XM 280JPK21R43aAiakn9YDa9rrUKK37LvAMNnvmjfvxRc2aJWSXMZgf7QcWc0gRjII3AMp q/qcZeBeO2Bw0QSTa7NptddFoRkBZt7IYHcBg7WirwjKNUXX6+5oLgf8rZIJUstq40ki iZXGCOCQOEuE1HqhvhXk4xz/N17mtdSwMkcs0btg/8oa4jX9xGAYPWYVLcEPYsFEG/2V /vRQ== MIME-Version: 1.0 X-Received: by 10.140.29.55 with SMTP id a52mr37093535qga.25.1432063958355; Tue, 19 May 2015 12:32:38 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Tue, 19 May 2015 12:32:38 -0700 (PDT) In-Reply-To: References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> Date: Tue, 19 May 2015 12:32:38 -0700 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: NGie Cooper To: Alexander Kabaev Cc: Sean Bruno , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:32:39 -0000 On Mon, May 18, 2015 at 5:29 PM, NGie Cooper wrote: > As a sidenote, this has been broken for over a decade: > https://svnweb.freebsd.org/base?view=revision&revision=127204 :(... -O is synonymous with -O2 (both on clang and gcc) :(... which means that the if/else statement has been bogus with clang for several years now. Argh... -O0 is what we've needed... From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 19:41:43 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA972F44; Tue, 19 May 2015 19:41:43 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 CC5571CA1; Tue, 19 May 2015 19:41:43 +0000 (UTC) Received: from [10.200.10.198] (unknown [209.119.89.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 229A5193893; Tue, 19 May 2015 19:41:42 +0000 (UTC) Message-ID: <555B91E8.2050803@ignoranthack.me> Date: Tue, 19 May 2015 12:41:28 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brooks Davis CC: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> In-Reply-To: <20150519165332.GA36377@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:41:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/19/15 09:53, Brooks Davis wrote: > On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote: > Following the External Tool Chain instructions on the wiki seem to > not work: https://wiki.freebsd.org/ExternalToolchain > > I've gotten about this far: > https://people.freebsd.org/~sbruno/clang_head_build_log.txt > >> You need to delete >> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* >> and possibly also limits.h (it's broken for libstand on mips). >> If you use the ports/pkgs they do this. This didn't seem to make any difference when xcompiling for AMD64, but I did run into a buildfailure which might mean I don't know what I'm doing: ===> lib/libstand (all) /home/sbruno/bsd/clang/build/bin/clang -target x86_64-unknown-freebsd11.0 - --sysroot=/var/tmp/home/sbruno/bsd/fbsd_head/tmp - -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/ bin -O2 -pipe -ffreestanding -Wformat - -I/home/sbruno/bsd/fbsd_head/lib/libstand -mno-mmx -mno-3dnow -mno-sse - -mno-sse2 -mno-sse3 -msoft-float -fPIC -mno-red-zone -DB Z_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - -I/home/sbruno/bsd/fbsd_head/lib/libstand/../libz -std=gnu99 - -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse d-const-variable -Wno-tautological-compare -Wno-unused-value - -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion - -Wno-unused-local-typedef -Wno-switch - Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses - -Qunused-arguments -c /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c -o strcspn.o /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:46:31: error: use of undeclared identifier 'LONG_BIT' u_long tbl[(UCHAR_MAX + 1) / LONG_BIT]; ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:60:9: error: use of undeclared identifier 'LONG_BIT' idx = IDX(*charset); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: note: expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:61:9: error: use of undeclared identifier 'LONG_BIT' bit = BIT(*charset); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: note: expanded from macro 'BIT' #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:66:9: error: use of undeclared identifier 'LONG_BIT' idx = IDX(*s1); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: note: expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:67:9: error: use of undeclared identifier 'LONG_BIT' bit = BIT(*s1); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: note: expanded from macro 'BIT' #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) ^ 5 errors generated. *** Error code 1 > > Two items of note. -- The bootstrap bits *completely* ignore XCC > and build with the host cc/c++ > >> That's expected. In principle clang could be used as the cross >> compiler since it's multi-target, but gcc could never work unless >> the host and target are the same. > > -- No documentation of what CFLAGS are required to build and > ignore warnings. > >> It will change with every clang/gcc release. In practice you >> will need to either fix the warnings wack-a-mole style or set >> NO_WERROR in the environment. > >> -- Brooks > > > Anyone out there have success doing this? > > sean >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To >> unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVW5HgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kXuIH/ia5UTjDxWfc6JdjkSbGgA1n JFsY/d0VpFdtXVtcSFQ6hYn2SMqhKCFSKxMkeByTclM0xJddljwHiyMBM4z692wv B9ozMK9sgiiuNFiVRTHELmcxbR5rFd2sP6g5WaafcBopvk/RpsRUpkrEWbe7uj9B n8Ox7AbNiG7oWK2ki1/ngl9HBe4Iml7E4Obj01tBegYIx6YeZ9LD4VRTLgXtpLDy 1ZeG+gFNQQ237+3VxS78mFXDZRkyxnrWH5ltQ9zcTjI5zOmSmMOngquoK/8Jin2y xCSgV4C/ce31JSSeW/AA3I6WixswjoKU9lTpKKK7aZgcIxBrN8oLN10I8E4NL8o= =Ro9f -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 19:41:44 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D61FF46; Tue, 19 May 2015 19:41:44 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 CC5B31CA2; Tue, 19 May 2015 19:41:43 +0000 (UTC) Received: from [10.200.10.198] (unknown [209.119.89.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1D8E5193656; Tue, 19 May 2015 19:41:42 +0000 (UTC) Message-ID: <555B91E8.9010309@ignoranthack.me> Date: Tue, 19 May 2015 12:41:28 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brooks Davis CC: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> In-Reply-To: <20150519165332.GA36377@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:41:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/19/15 09:53, Brooks Davis wrote: > On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote: > Following the External Tool Chain instructions on the wiki seem to > not work: https://wiki.freebsd.org/ExternalToolchain > > I've gotten about this far: > https://people.freebsd.org/~sbruno/clang_head_build_log.txt > >> You need to delete >> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* >> and possibly also limits.h (it's broken for libstand on mips). If >> you use the ports/pkgs they do this. This didn't seem to make any difference when xcompiling for AMD64, but I did run into a buildfailure which might mean I don't know what I'm doing: ===> lib/libstand (all) /home/sbruno/bsd/clang/build/bin/clang -target x86_64-unknown-freebsd11.0 - --sysroot=/var/tmp/home/sbruno/bsd/fbsd_head/tmp - -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/ bin -O2 -pipe -ffreestanding -Wformat - -I/home/sbruno/bsd/fbsd_head/lib/libstand -mno-mmx -mno-3dnow -mno-sse - -mno-sse2 -mno-sse3 -msoft-float -fPIC -mno-red-zone -DB Z_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - -I/home/sbruno/bsd/fbsd_head/lib/libstand/../libz -std=gnu99 - -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse d-const-variable -Wno-tautological-compare -Wno-unused-value - -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion - -Wno-unused-local-typedef -Wno-switch - Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses - -Qunused-arguments -c /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c -o strcspn.o /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:46:31: error: use of undeclared identifier 'LONG_BIT' u_long tbl[(UCHAR_MAX + 1) / LONG_BIT]; ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:60:9: error: use of undeclared identifier 'LONG_BIT' idx = IDX(*charset); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: note: expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:61:9: error: use of undeclared identifier 'LONG_BIT' bit = BIT(*charset); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: note: expanded from macro 'BIT' #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:66:9: error: use of undeclared identifier 'LONG_BIT' idx = IDX(*s1); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: note: expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:67:9: error: use of undeclared identifier 'LONG_BIT' bit = BIT(*s1); ^ /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: note: expanded from macro 'BIT' #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) ^ 5 errors generated. *** Error code 1 > > Two items of note. -- The bootstrap bits *completely* ignore XCC > and build with the host cc/c++ > >> That's expected. In principle clang could be used as the cross >> compiler since it's multi-target, but gcc could never work >> unless the host and target are the same. > > -- No documentation of what CFLAGS are required to build and ignore > warnings. > >> It will change with every clang/gcc release. In practice you >> will need to either fix the warnings wack-a-mole style or set >> NO_WERROR in the environment. > >> -- Brooks > > > Anyone out there have success doing this? > > sean >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To >> unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVW5HhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5keYAIAJ2QVVw6K6UDXnn7+MzI3U6s agPzhREr8HB0wZDapUjjtG+KVdy0P3bPKX+T5D4nDq8YbW7EgkYJcYL+A2xl0Ri9 sXHldlTHdf43XRtFufbYpM6z6X4SZ8wHo67F+UuIPmPjnn8GSLd6b4bORrhvvmdN fy2X3eDSBs8ogssJSWLYHCPA3hGWeAlXUMy1abv5wuEc4cxQmYjW3dY4l019nC0r jSTPd1JDacW6rMUMXFx1aZDsk9nk2Xl1khUu2bR0ZiMkdVYD1s0JhNF4UQYMqPsN 3u8FK0RFnOTN8XgVNb4mjqgSMGMigrpvtoPdhrqcscOewgjPORoypL/f6xVmejc= =G80s -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 20:21:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54AD27A4; Tue, 19 May 2015 20:21:54 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 30E0010E2; Tue, 19 May 2015 20:21:53 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 0B2CC5A9F27; Tue, 19 May 2015 20:21:53 +0000 (UTC) Date: Tue, 19 May 2015 20:21:53 +0000 From: Brooks Davis To: sbruno@freebsd.org Cc: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC Message-ID: <20150519202153.GB36377@spindle.one-eyed-alien.net> References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <555B91E8.9010309@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:21:54 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 12:41:28PM -0700, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 05/19/15 09:53, Brooks Davis wrote: > > On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote:=20 > > Following the External Tool Chain instructions on the wiki seem to=20 > > not work: https://wiki.freebsd.org/ExternalToolchain > >=20 > > I've gotten about this far:=20 > > https://people.freebsd.org/~sbruno/clang_head_build_log.txt > >=20 > >> You need to delete=20 > >> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std*=20 > >> and possibly also limits.h (it's broken for libstand on mips). If > >> you use the ports/pkgs they do this. >=20 > This didn't seem to make any difference when xcompiling for AMD64, but > I did run into a buildfailure which might mean I don't know what I'm > doing: rm /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/limits.h should do get around this one. I hit this one on mips a few weeks ago. It's a bug in upstream clang that the bundled limits.h doesn't #include_next with -ffreestanding. I've not had a chance to submit a review request to fix it. -- Brooks >=20 >=20 > =3D=3D=3D> lib/libstand (all) > /home/sbruno/bsd/clang/build/bin/clang -target > x86_64-unknown-freebsd11.0 > - --sysroot=3D/var/tmp/home/sbruno/bsd/fbsd_head/tmp > - -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/ > bin -O2 -pipe -ffreestanding -Wformat > - -I/home/sbruno/bsd/fbsd_head/lib/libstand -mno-mmx -mno-3dnow -mno-sse > - -mno-sse2 -mno-sse3 -msoft-float -fPIC -mno-red-zone -DB > Z_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY > - -I/home/sbruno/bsd/fbsd_head/lib/libstand/../libz -std=3Dgnu99 > - -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse > d-const-variable -Wno-tautological-compare -Wno-unused-value > - -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > - -Wno-unused-local-typedef -Wno-switch - > Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses > - -Qunused-arguments -c > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c -o > strcspn.o > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:46:31: > error: > use of undeclared identifier 'LONG_BIT' > u_long tbl[(UCHAR_MAX + 1) / LONG_BIT]; > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:60:9: > error: use of undeclared identifier 'LONG_BIT' > idx =3D IDX(*charset); > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: > note: > expanded from macro 'IDX' > #define IDX(c) ((u_char)(c) / LONG_BIT) > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:61:9: > error: use of undeclared identifier 'LONG_BIT' > bit =3D BIT(*charset); > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: > note: > expanded from macro 'BIT' > #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:66:9: > error: use of undeclared identifier 'LONG_BIT' > idx =3D IDX(*s1); > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31: > note: > expanded from macro 'IDX' > #define IDX(c) ((u_char)(c) / LONG_BIT) > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:67:9: > error: use of undeclared identifier 'LONG_BIT' > bit =3D BIT(*s1); > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45: > note: > expanded from macro 'BIT' > #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) > ^ > 5 errors generated. > *** Error code 1 >=20 >=20 >=20 > >=20 > > Two items of note. -- The bootstrap bits *completely* ignore XCC=20 > > and build with the host cc/c++ > >=20 > >> That's expected. In principle clang could be used as the cross=20 > >> compiler since it's multi-target, but gcc could never work > >> unless the host and target are the same. > >=20 > > -- No documentation of what CFLAGS are required to build and ignore > > warnings. > >=20 > >> It will change with every clang/gcc release. In practice you=20 > >> will need to either fix the warnings wack-a-mole style or set=20 > >> NO_WERROR in the environment. > >=20 > >> -- Brooks > >=20 > >=20 > > Anyone out there have success doing this? > >=20 > > sean > >> _______________________________________________=20 > >> freebsd-hackers@freebsd.org mailing list=20 > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To=20 > >> unsubscribe, send any mail to=20 > >> "freebsd-hackers-unsubscribe@freebsd.org" > >>=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQF8BAEBCgBmBQJVW5HhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5keYAIAJ2QVVw6K6UDXnn7+MzI3U6s > agPzhREr8HB0wZDapUjjtG+KVdy0P3bPKX+T5D4nDq8YbW7EgkYJcYL+A2xl0Ri9 > sXHldlTHdf43XRtFufbYpM6z6X4SZ8wHo67F+UuIPmPjnn8GSLd6b4bORrhvvmdN > fy2X3eDSBs8ogssJSWLYHCPA3hGWeAlXUMy1abv5wuEc4cxQmYjW3dY4l019nC0r > jSTPd1JDacW6rMUMXFx1aZDsk9nk2Xl1khUu2bR0ZiMkdVYD1s0JhNF4UQYMqPsN > 3u8FK0RFnOTN8XgVNb4mjqgSMGMigrpvtoPdhrqcscOewgjPORoypL/f6xVmejc=3D > =3DG80s > -----END PGP SIGNATURE----- >=20 --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVW5tfAAoJEKzQXbSebgfAj2EH/02PFtR7hITNY7kxlZjfoaq8 00DlBmaewGGUH7ZmCv4t7rYx3qkv/1AB7PmKbBDbtdsRsznjXtVWHcsdBuu8PQfJ PYjvWNXXcFWjhEnIdSi2MmtWBmbhKZM7G2B/ncE5z7yVqMc0022ALkgolALjxFMc uKt+53D4jjQAmzwaL6oyqaTNOfjax1XIrhhH64sdEaEPqMxuaKT573pd/F40zDWi qunZ8Jh79AonlEpq+aAgYxBq6wxFS4+3w+5W4PFAU3CnMq3FdCrSjoYxYvxrtk7t yTfngxSMvoc9rrIiVF6vzTpSrF4wi4RasYTEyWdq7yrINaD8QfuGiUh8xR/xEo0= =QbXY -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 20:35:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89706A5A for ; Tue, 19 May 2015 20:35:33 +0000 (UTC) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 53ED2120E for ; Tue, 19 May 2015 20:35:33 +0000 (UTC) Received: by oihb9 with SMTP id b9so20641423oih.3 for ; Tue, 19 May 2015 13:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=/xosaHSIgDzxD8ieT6xsBaeoOBGATKwf0IHL4j3+zXE=; b=l3Y81sIIXQTdw4ko5onxpisDP62n64jqaznD4JGQ+fkhhhZKyhsSDBkOsiLZopW1HS TreduIjrGv24fc/Mx3KTSkaUBnf8JGi7Pq0F0kAnuLO1Tn8vpuzAWYoXumyp8+jn8c2b jWY7GkS/ecPSIKpp3FN1G1FIFLWNUzYusiQ57BGf2FYzdWWyDsyPWDijYWZbMfwLT8Ln gY9IC/4s8q+M7pxI2831sRwGfygnWHsU6PnF7qSKoF3XFcHoVFPuBqEEflUZinlOXWsW a5SxqWQ6vEbZ5AcedG2bNK1gWOKRV3vjfyMAlyDIFnG+/GePhDhUj/Y6tnjH3B47OknY 8MYg== MIME-Version: 1.0 X-Received: by 10.182.186.4 with SMTP id fg4mr22029619obc.7.1432067732791; Tue, 19 May 2015 13:35:32 -0700 (PDT) Received: by 10.202.199.131 with HTTP; Tue, 19 May 2015 13:35:32 -0700 (PDT) Reply-To: dave@sopwith.solgatos.com Date: Tue, 19 May 2015 13:35:32 -0700 Message-ID: Subject: Re: Trying to use clang/head and XCC From: Dave Seifert To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 19 May 2015 20:42:51 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:35:33 -0000 sean typed: > No documentation of what CFLAGS are required to build and ignore warnings. Are you *sure* that ignoring those warnings is a good idea? Brooks typed: > In principle clang could be used as the cross compiler > since it's multi-target, but gcc could never work unless the host and > target are the same. I have compiled NetBSD/alpha on FreeBSD/amd64 using gcc and it worked fine. From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 21:17:40 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34BDC652 for ; Tue, 19 May 2015 21:17:40 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 12EEC16CE for ; Tue, 19 May 2015 21:17:39 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 31C715A9F25; Tue, 19 May 2015 21:17:39 +0000 (UTC) Date: Tue, 19 May 2015 21:17:39 +0000 From: Brooks Davis To: dave@sopwith.solgatos.com Cc: freebsd-hackers@freebsd.org Subject: Re: Trying to use clang/head and XCC Message-ID: <20150519211739.GA67904@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:17:40 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 01:35:32PM -0700, Dave Seifert wrote: > sean typed: > > No documentation of what CFLAGS are required to build and ignore warnin= gs. >=20 > Are you *sure* that ignoring those warnings is a good idea? >=20 > Brooks typed: > > In principle clang could be used as the cross compiler > > since it's multi-target, but gcc could never work unless the host and > > target are the same. >=20 > I have compiled NetBSD/alpha on FreeBSD/amd64 using gcc and it worked fin= e. A single gcc binary will only allow you to build for one target so you could only use the same gcc for bootstrap tools and the target if they happen to be the same. We could support external compilers for both cases, but that's not what I implemented with the X* cross tool support. -- Brooks --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVW6hyAAoJEKzQXbSebgfAFO0IAJ1Xd8IswjIuiA9lx5U23sch 6HfOQGqWMxNHAHsOzTvPMixLj25SWpABT2nkMptXl3l7BedLDiQl4uQ+ti0CSQdm xqR1T+KFO0VywzQkbVg7H5/oFDpDL8PHPa8A2wND91AjIetAvJ5RQRSDPRwHkTUX LgknJIbrkCgZ2wBXnLxevp4X/iaSHUfTjslp26gmRYySwGRuVTta9QAzrW7C4tD0 5OXVTPnEdGo0e8XAmtTTkoFpU1W88td/R8TZfrDRcbkT8kLm99yw23dffhO9QYyy 4THCyNHxrdOhYvl5JDIX99icJjLEMl/Gq2X35zDGs7WQFRFYoSYt3EC7CsNJU/4= =ERMd -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 22:04:21 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65DCD910; Tue, 19 May 2015 22:04:21 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0066.outbound.protection.outlook.com [65.55.169.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9494B1C85; Tue, 19 May 2015 22:04:19 +0000 (UTC) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (25.162.218.25) by SN1PR0801MB1566.namprd08.prod.outlook.com (25.163.133.156) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 19 May 2015 22:04:11 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([25.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([25.162.218.25]) with mapi id 15.01.0160.009; Tue, 19 May 2015 22:04:11 +0000 From: "Pokala, Ravi" To: "freebsd-net@freebsd.org" , "jfv@freebsd.org" , "erj@freebsd.org" CC: "freebsd-hackers@freebsd.org" , "Lewis, Fred" , "Sundararajan, Lakshmi" Subject: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Topic: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Index: AQHQkn+7WBa4imHGwkeMI3kSTJaMlQ== Date: Tue, 19 May 2015 22:04:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0801MB1566; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0801MB1566; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0801MB1566; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(164054003)(5001960100002)(189998001)(5001830100001)(5001860100001)(5001770100001)(106356001)(106116001)(102836002)(2900100001)(83506001)(229853001)(36756003)(50986999)(54356999)(101416001)(64706001)(4001540100001)(86362001)(2656002)(87936001)(66066001)(2201001)(97736004)(81156007)(92566002)(40100003)(77156002)(46102003)(2501003)(4001350100001)(122556002)(68736005)(62966003)(105586002)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0801MB1566; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 22:04:10.2974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0801MB1566 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:04:21 -0000 Hi folks, At Panasas, we are working with the Intel XL710 40G NIC (aka Fortville), and we're seeing some performance issues w/ 11-CURRENT (r282653). Motherboard: Intel S2600KP (aka Kennedy Pass) CPU: E5-2660 v3 @ 2.6GHz (aka Haswell Xeon) (1 socket x 10 physical cores x 2 SMT threads) =3D 20 logical cores NIC: Intel XL710, 2x40Gbps QSFP, configured in 4x10Gbps mode RAM: 4x 16GB DDR4 DIMMs What we've seen so far: - TX performance is pretty consistently lower than RX performance. All numbers below are for unidrectional tests using `iperf': 10Gbps links threads/link TX Gbps RX Gbps TX/RX 1 1 9.02 9.85 91.57% 1 8 8.49 9.91 85.67% 1 16 7.00 9.91 70.63% 1 32 6.68 9.92 67.40% - With multiple active links, both TX and RX performance suffer greatly; the aggregate bandwidth tops out at about a third of the theoretical 40Gbps implied by 4x 10Gbps. 10Gbps links threads/link TX Gbps RX Gbps % of 40Gbps 4 1 13.39 13.38 33.4% - Multi-link bidirectional throughput is absolutely terrible; the aggregate is less than a tenth of the theoretical 40Gbps. 10Gbps links threads/link TX Gbps RX Gbps % of 40Gbps 4 1 3.83 2.96 9.6% / 7.4% - Occasional interrupt storm messages are seen from the IRQs associated with the NICs. Since that can impact performance, those runs were not included in the data listed above. Our questions: - How stable is ixl(4) in -CURRENT? By that, we mean both how quickly is the driver changing, and does the driver cause any system instability? - What type of performance have others been getting w/ Fortville? In 40Gbps mode? In 4x10Gbps mode? - Does anyone have any tuning parameters they can recommend for this card? - We did our testing w/ 11-CURRENT, but we will initially ship Fortville running on 10.1-RELEASE or 10.2-RELEASE. The presence of RSS - even though it is disabled by default - makes the driver back-port non-trivial. Is there an estimate on when the 11-CURRENT version of the driver (1.4.1) will get MFCed to 10-STABLE? My colleagues Lakshmi and Fred (CCed) are working on this; please make sure to include them if you have any comments. Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 22:25:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7D07328 for ; Tue, 19 May 2015 22:25:57 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:0:20e:cff:fea0:e4a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 630C41EBF for ; Tue, 19 May 2015 22:25:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::9416:1fb6:b77b:39fb] (unknown [IPv6:2001:7b8:3a7:0:9416:1fb6:b77b:39fb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DAE27239FB; Wed, 20 May 2015 00:25:52 +0200 (CEST) Subject: Re: How to get anything useful out of kgdb? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0CED5C5B-CFB9-4493-86FA-26E7855890CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Wed, 20 May 2015 00:25:36 +0200 Cc: Alexander Kabaev , "freebsd-hackers@freebsd.org" , Sean Bruno Message-Id: <2CEF3F4B-286C-47C5-B170-6CC017BE9D61@FreeBSD.org> References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> To: NGie Cooper X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:25:57 -0000 --Apple-Mail=_0CED5C5B-CFB9-4493-86FA-26E7855890CE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 19 May 2015, at 21:32, NGie Cooper wrote: > > On Mon, May 18, 2015 at 5:29 PM, NGie Cooper wrote: > >> As a sidenote, this has been broken for over a decade: >> https://svnweb.freebsd.org/base?view=revision&revision=127204 :(... > > -O is synonymous with -O2 (both on clang and gcc) :(... No, for gcc -O has always meant -O1. For clang, it means -O2. If you want -O1, please specify it. :) Though with clang I don't think you will see too much difference regarding variables which have been put in registers, or eliminated altogether, making it harder to follow for gdb (especially the ancient version in base). If you want to have everything fully traceable, use -O0, and increase your kernel stack size, otherwise it is likely to blow up. -Dimitry --Apple-Mail=_0CED5C5B-CFB9-4493-86FA-26E7855890CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlVbuHAACgkQsF6jCi4glqMKvgCdGWG7yPtvWnYyhJw4WIm1C9rV koAAoIuY4LY2JuiICHrs4LlAh46L+UFj =K5AT -----END PGP SIGNATURE----- --Apple-Mail=_0CED5C5B-CFB9-4493-86FA-26E7855890CE-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 00:50:31 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2800AADA for ; Wed, 20 May 2015 00:50:31 +0000 (UTC) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 DA9591EF2 for ; Wed, 20 May 2015 00:50:30 +0000 (UTC) Received: by qkgw4 with SMTP id w4so22073928qkg.3 for ; Tue, 19 May 2015 17:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Fnu40AYTar0lzt39GC3U09Tc0Zfdy8lme1bVNobG5o=; b=R6NFConwGVF0idmwpJRurDpsUEw4Lqyxq24SeaIRj5bwZPXMw53/lQV2rBwIEClUwd pe7NZgEB5tk4OcGZDQbzkISPvSle3At+0c+NlP2DK9kBCJ1iVsMS8DylLIF+odArtzRt OZ8Ubpn/ALeQCQD3yu7qT7ogWQHuOjh19M4r4WP96uSvgDhOIonhvNHqdaeVC7p3m8T3 aWnNGQ0+M7qLSxlXxv0H6tDrLgTM3QF98eqdH2y4hFUsfz+OrgT+IP+QHJQgMXfu9GF4 N+Qrfv9cjj2KlvclX0UXTJGn0IunfEq0SRgvAHstVWnIsEu1abbLa7VGgHCetF2uTBHR kKCA== MIME-Version: 1.0 X-Received: by 10.141.18.136 with SMTP id u130mr39449983qhd.54.1432083029858; Tue, 19 May 2015 17:50:29 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Tue, 19 May 2015 17:50:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2015 17:50:29 -0700 Message-ID: Subject: Re: Trying to use clang/head and XCC From: NGie Cooper To: dave@sopwith.solgatos.com Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 00:50:31 -0000 On Tue, May 19, 2015 at 1:35 PM, Dave Seifert wrote: > sean typed: >> No documentation of what CFLAGS are required to build and ignore warnings. > > Are you *sure* that ignoring those warnings is a good idea? The problem is that clang emits a *lot* of warnings with -Wall that gcc doesn't, which causes failures if -Werror is enabled in the build (annoying, but I've run into this at work...). Please see my earlier reply about 10.0-RELEASE builds being broken on 11.0-CURRENT with clang 3.6.0. Also, gcc emits different warnings because (IIRC) it analyzes code that's been optimized whereas I believe clang does it beforehand (please correct me if I'm wrong). Thanks, -NGie From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 00:56:53 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DF75EDA; Wed, 20 May 2015 00:56:53 +0000 (UTC) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB4D31018; Wed, 20 May 2015 00:56:52 +0000 (UTC) Received: by qkgx75 with SMTP id x75so22210067qkg.1; Tue, 19 May 2015 17:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K/Jp/NsAIgA4/1HirqQyEEOL11gH1mfSWN6A/85fAig=; b=wWOVktKKnJoJAuVD5OpX3iC+GRhvnUv2fseT43psmoFKHTS6OVUg6/hJ/G0r3akS4P 3gqlv92wrcTx0ottF5jm3SYHQ1PwsJBM3AATqmCtaHu+cm1WqMBNGPjfOQYHeVuux04g nevOgRoKaV1MdI3T4GCPfaaMAgr6YZ7dwT0cHz6l0NYQs14PuNtMYTkHK+kMyEn+Y84g R4SqOW6KUtaUqwCrDLWSKtb0q3yk1mKuAH8bG63QyFpra7wnzQLXN+VgfkpQol+yD8LM Ua4lxqjrl9FJsGIGSvmDFTqzOsjknMZ8+znJs3CcyX6U+Ya2ZX4S/noac9UQm9HEXS+J bmQw== MIME-Version: 1.0 X-Received: by 10.140.90.99 with SMTP id w90mr38953579qgd.57.1432083412162; Tue, 19 May 2015 17:56:52 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Tue, 19 May 2015 17:56:52 -0700 (PDT) In-Reply-To: <2CEF3F4B-286C-47C5-B170-6CC017BE9D61@FreeBSD.org> References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> <2CEF3F4B-286C-47C5-B170-6CC017BE9D61@FreeBSD.org> Date: Tue, 19 May 2015 17:56:52 -0700 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: NGie Cooper To: Dimitry Andric Cc: Alexander Kabaev , "freebsd-hackers@freebsd.org" , Sean Bruno Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 00:56:53 -0000 On Tue, May 19, 2015 at 3:25 PM, Dimitry Andric wrote: > On 19 May 2015, at 21:32, NGie Cooper wrote: >> >> On Mon, May 18, 2015 at 5:29 PM, NGie Cooper wrote: >> >>> As a sidenote, this has been broken for over a decade: >>> https://svnweb.freebsd.org/base?view=revision&revision=127204 :(... >> >> -O is synonymous with -O2 (both on clang and gcc) :(... > > No, for gcc -O has always meant -O1. For clang, it means -O2. If you > want -O1, please specify it. :) My bad. I typoed this earlier. > Though with clang I don't think you will see too much difference > regarding variables which have been put in registers, or eliminated > altogether, making it harder to follow for gdb (especially the ancient > version in base). > > If you want to have everything fully traceable, use -O0, and increase > your kernel stack size, otherwise it is likely to blow up. But *how* do you do that (especially when the build infrastructure gets in the way of you setting this)? Turns out there is a way if you dig deep enough through sys/conf/NOTES and are willing to abuse a feature... 62 # 63 # The `makeoptions' parameter allows variables to be passed to the 64 # generated Makefile in the build area. 65 # 66 # CONF_CFLAGS gives some extra compiler flags that are added to ${CFLAGS} 67 # after most other flags. Here we use it to inhibit use of non-optimal 68 # gcc built-in functions (e.g., memcmp). 69 # 70 # DEBUG happens to be magic. 71 # The following is equivalent to 'config -g KERNELNAME' and creates 72 # 'kernel.debug' compiled with -g debugging as well as a normal 73 # 'kernel'. Use 'make install.debug' to install the debug kernel 74 # but that isn't normally necessary as the debug symbols are not loaded 75 # by the kernel and are not useful there anyway. 76 # 77 # KERNEL can be overridden so that you can change the default name of your 78 # kernel. 79 # 80 # MODULES_OVERRIDE can be used to limit modules built to a specific list. 81 # 82 makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc. 5 makeoptions CONF_CFLAGS=-O2 I wouldn't expect most folks to figure this out though, and it requires manual intervention in your kernel configuration to do this, even though DEBUG is set. This is not desirable for debug builds out of the box nor for folks who are trying to use makeoptions DEBUG=-g in their KERNCONFs. Cheers, -NGie From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 01:47:16 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D59F5FE6; Wed, 20 May 2015 01:47:16 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 A0F93165E; Wed, 20 May 2015 01:47:16 +0000 (UTC) Received: from [192.168.168.121] (wsip-98-172-74-163.ph.ph.cox.net [98.172.74.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id D7394193656; Wed, 20 May 2015 01:47:14 +0000 (UTC) Message-ID: <555BE7A1.3040808@ignoranthack.me> Date: Tue, 19 May 2015 18:47:13 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brooks Davis CC: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> <20150519202153.GB36377@spindle.one-eyed-alien.net> In-Reply-To: <20150519202153.GB36377@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 01:47:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/19/15 13:21, Brooks Davis wrote: > On Tue, May 19, 2015 at 12:41:28PM -0700, Sean Bruno wrote: On > 05/19/15 09:53, Brooks Davis wrote: >>>> On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote: >>>> Following the External Tool Chain instructions on the wiki >>>> seem to not work: https://wiki.freebsd.org/ExternalToolchain >>>> >>>> I've gotten about this far: >>>> https://people.freebsd.org/~sbruno/clang_head_build_log.txt >>>> >>>>> You need to delete >>>>> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* >>>>> and possibly also limits.h (it's broken for libstand on >>>>> mips). If you use the ports/pkgs they do this. > > This didn't seem to make any difference when xcompiling for AMD64, > but I did run into a buildfailure which might mean I don't know > what I'm doing: > >> rm >> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/limits.h > >> should do get around this one. I hit this one on mips a few >> weeks ago. > >> It's a bug in upstream clang that the bundled limits.h doesn't >> #include_next with -ffreestanding. I've not had a >> chance to submit a review request to fix it. > >> -- Brooks > > > > ===> lib/libstand (all) /home/sbruno/bsd/clang/build/bin/clang > -target x86_64-unknown-freebsd11.0 > --sysroot=/var/tmp/home/sbruno/bsd/fbsd_head/tmp > -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/ bin -O2 -pipe > -ffreestanding -Wformat -I/home/sbruno/bsd/fbsd_head/lib/libstand > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fPIC > -mno-red-zone -DB Z_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY > -I/home/sbruno/bsd/fbsd_head/lib/libstand/../libz -std=gnu99 > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse > d-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch - > Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses > -Qunused-arguments -c > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c > -o strcspn.o > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:46:31 : > > error: > use of undeclared identifier 'LONG_BIT' u_long tbl[(UCHAR_MAX + 1) > / LONG_BIT]; ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:60:9: > > error: use of undeclared identifier 'LONG_BIT' > idx = IDX(*charset); ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31 : > > note: > expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:61:9: > > error: use of undeclared identifier 'LONG_BIT' > bit = BIT(*charset); ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45 : > > note: > expanded from macro 'BIT' #define BIT(c) ((u_long)1 << > ((u_char)(c) % LONG_BIT)) ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:66:9: > > error: use of undeclared identifier 'LONG_BIT' > idx = IDX(*s1); ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:34:31 : > > note: > expanded from macro 'IDX' #define IDX(c) ((u_char)(c) / LONG_BIT) > ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:67:9: > > error: use of undeclared identifier 'LONG_BIT' > bit = BIT(*s1); ^ > /home/sbruno/bsd/fbsd_head/lib/libstand/../libc/string/strcspn.c:35:45 : > > note: > expanded from macro 'BIT' #define BIT(c) ((u_long)1 << > ((u_char)(c) % LONG_BIT)) ^ 5 errors generated. *** Error code 1 > > > >>>> >>>> Two items of note. -- The bootstrap bits *completely* ignore >>>> XCC and build with the host cc/c++ >>>> >>>>> That's expected. In principle clang could be used as the >>>>> cross compiler since it's multi-target, but gcc could never >>>>> work unless the host and target are the same. >>>> >>>> -- No documentation of what CFLAGS are required to build and >>>> ignore warnings. >>>> >>>>> It will change with every clang/gcc release. In practice >>>>> you will need to either fix the warnings wack-a-mole style >>>>> or set NO_WERROR in the environment. >>>> >>>>> -- Brooks >>>> >>>> >>>> Anyone out there have success doing this? >>>> >>>> sean Getting much closer, I think this is fixable, but maybe we need to pass this upstream? ===> sys/boot/i386/boot2 (depend) ln -sf /home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../../../i386/include machine /home/sbruno/bsd/clang/build/bin/clang -target x86_64-unknown-freebsd11.0 - --sysroot=/var/tmp/home/sbruno/bsd/fbsd_head/tmp - -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/bin -fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 - -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 - -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../../common - -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../btx/lib -I. -Wall - -Waggregate-return -Wbad-function-cast -Wcast-align - -Wmissing-declarations -Wmissing-prototypes -Wnested-externs - -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline - -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 - -mno-sse3 -msoft-float -m32 -std=gnu99 -Oz -mstack-alignment=8 - -mllvm -inline-threshold=3 -mllvm -simplifycfg-dup-ret -mllvm - -enable-gvn=false -Qunused-arguments -no-integrated-as -m32 -c /home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/boot1.S -o boot1.o clang (LLVM option parsing): Unknown command line argument '-enable-gvn=false'. Try: 'clang (LLVM option parsing) -help' clang (LLVM option parsing): Did you mean '-enable-pre=false'? *** Error code 1 Stop. make[6]: stopped in /home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2 *** Error code 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVW+eeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kYDAH/iWF3lKAdEfOK2VN5IWPhzm2 eIBs5OO8cAOhxp79oQP/668WxzjF2sGcgSLzURNvle25iYDwNbeBmGphxycs+5+A /Bidkq9qBDPo4kz8+2tb1cil+QMT3JnoiuVh66ICnCPCNJSkYibuyTlaaB/y0Gg+ OanQEtvsZ8ZQYfesE0SIhXn4w7EDoyh9FsBVerusKBIvyUze3W/c6tQblHY+qZvM 4HQuOZYZC8qPplG8cREFtIemkdp0M7e1atw8o3gss0JkIRCHzPsEh6ekbwuSxXT+ gUDE0H1odTSO0YsJRbLhi/LWvuyg5oDwiAkP+QmPgO44VeCGybIAhtRKjgzErFA= =XPVp -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 04:52:36 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06AB4D62; Wed, 20 May 2015 04:52:36 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id B963B1B4E; Wed, 20 May 2015 04:52:35 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B7AB85A9F25; Wed, 20 May 2015 04:52:34 +0000 (UTC) Date: Wed, 20 May 2015 04:52:34 +0000 From: Brooks Davis To: sbruno@freebsd.org Cc: Brooks Davis , dim@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC Message-ID: <20150520045234.GA83978@spindle.one-eyed-alien.net> References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> <20150519202153.GB36377@spindle.one-eyed-alien.net> <555BE7A1.3040808@ignoranthack.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <555BE7A1.3040808@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 04:52:36 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 06:47:13PM -0700, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 05/19/15 13:21, Brooks Davis wrote: > > On Tue, May 19, 2015 at 12:41:28PM -0700, Sean Bruno wrote: On > > 05/19/15 09:53, Brooks Davis wrote: > >>>> On Tue, May 19, 2015 at 09:23:42AM -0700, Sean Bruno wrote:=20 > >>>> Following the External Tool Chain instructions on the wiki > >>>> seem to not work: https://wiki.freebsd.org/ExternalToolchain > >>>>=20 > >>>> I've gotten about this far:=20 > >>>> https://people.freebsd.org/~sbruno/clang_head_build_log.txt > >>>>=20 > >>>>> You need to delete=20 > >>>>> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/std* > >>>>> and possibly also limits.h (it's broken for libstand on > >>>>> mips). If you use the ports/pkgs they do this. > >=20 > > This didn't seem to make any difference when xcompiling for AMD64, > > but I did run into a buildfailure which might mean I don't know > > what I'm doing: > >=20 > >> rm > >> /home/sbruno/bsd/clang/build/bin/../lib/clang/3.7.0/include/limits.h > > > >> should do get around this one. I hit this one on mips a few > >> weeks ago. > >=20 > >> It's a bug in upstream clang that the bundled limits.h doesn't=20 > >> #include_next with -ffreestanding. I've not had a > >> chance to submit a review request to fix it. > >=20 > >> -- Brooks > >>>>=20 > >>>> Two items of note. -- The bootstrap bits *completely* ignore > >>>> XCC and build with the host cc/c++ > >>>>=20 > >>>>> That's expected. In principle clang could be used as the > >>>>> cross compiler since it's multi-target, but gcc could never > >>>>> work unless the host and target are the same. > >>>>=20 > >>>> -- No documentation of what CFLAGS are required to build and > >>>> ignore warnings. > >>>>=20 > >>>>> It will change with every clang/gcc release. In practice > >>>>> you will need to either fix the warnings wack-a-mole style > >>>>> or set NO_WERROR in the environment. > >>>>=20 > >>>>> -- Brooks > >>>>=20 > >>>>=20 > >>>> Anyone out there have success doing this? > >>>>=20 > >>>> sean >=20 >=20 >=20 > Getting much closer, I think this is fixable, but maybe we need to > pass this upstream? > =3D=3D=3D> sys/boot/i386/boot2 (depend) > ln -sf > /home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../../../i386/include > machine > /home/sbruno/bsd/clang/build/bin/clang -target > x86_64-unknown-freebsd11.0 > - --sysroot=3D/var/tmp/home/sbruno/bsd/fbsd_head/tmp > - -B/var/tmp/home/sbruno/bsd/fbsd_head/tmp/usr/bin -fomit-frame-pointer > -mrtd -mregparm=3D3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=3D0x80 > - -DSIOPRT=3D0x3f8 -DSIOFMT=3D0x3 -DSIOSPD=3D9600 > - -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../../common > - -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/../btx/lib -I. -Wall > - -Waggregate-return -Wbad-function-cast -Wcast-align > - -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > - -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline > - -march=3Di386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > - -mno-sse3 -msoft-float -m32 -std=3Dgnu99 -Oz -mstack-alignment=3D8 > - -mllvm -inline-threshold=3D3 -mllvm -simplifycfg-dup-ret -mllvm > - -enable-gvn=3Dfalse -Qunused-arguments -no-integrated-as -m32 -c > /home/sbruno/bsd/fbsd_head/sys/boot/i386/boot2/boot1.S -o boot1.o > clang (LLVM option parsing): Unknown command line argument > '-enable-gvn=3Dfalse'. Try: 'clang (LLVM option parsing) -help' > clang (LLVM option parsing): Did you mean '-enable-pre=3Dfalse'? > *** Error code 1 IIRC -enable-gvn=3Dfalse is a local option Dimitry added to our clang. I d= on't remember the suggested workaround off hand. -- Brooks --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVXBMSAAoJEKzQXbSebgfAyG4H/jAy//hjfmvVTjoGh/3xXLfk gCSwO1or7JdY4JqTpXALQZe9o+OHlCrxITxZjRs3pAf/KCk1yKiibdV78YN54tAb XATzC+L0BOFAGyCmHcSwdArCswOfmWmROGYb0CkbJzSybU3QUpE6Th3/416KY7+a +PDI613yTKYYd0V6iTxa1Bfz3BRf3+01OUp47UC/mxTU1K4yjy5iGO3JL6T42IGX Ep8R+8BQqNoLX43FESqKaXQAwWLMf6olJHMDwpTD5Xv5bAM+aA8ZahYcVGTA135F 4grCl4DgvDGvkGIdm5NO20hZMROb+sXs8HUn/D+eKuyoAmcfKeXzYah++h6U6q0= =VXvd -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 06:10:13 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B13499C; Wed, 20 May 2015 06:10:13 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA8B312A5; Wed, 20 May 2015 06:10:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::9416:1fb6:b77b:39fb] (unknown [IPv6:2001:7b8:3a7:0:9416:1fb6:b77b:39fb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 93F8D23F94; Wed, 20 May 2015 08:10:04 +0200 (CEST) Subject: Re: Trying to use clang/head and XCC Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C1AAB1AA-34BA-4704-BA5D-EAD715DA29E4"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <20150520045234.GA83978@spindle.one-eyed-alien.net> Date: Wed, 20 May 2015 08:09:53 +0200 Cc: sbruno@freebsd.org, "freebsd-hackers@freebsd.org" Message-Id: References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> <20150519202153.GB36377@spindle.one-eyed-alien.net> <555BE7A1.3040808@ignoranthack.me> <20150520045234.GA83978@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 06:10:13 -0000 --Apple-Mail=_C1AAB1AA-34BA-4704-BA5D-EAD715DA29E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 May 2015, at 06:52, Brooks Davis wrote: >=20 > On Tue, May 19, 2015 at 06:47:13PM -0700, Sean Bruno wrote: ... >> clang (LLVM option parsing): Unknown command line argument >> '-enable-gvn=3Dfalse'. Try: 'clang (LLVM option parsing) -help' >> clang (LLVM option parsing): Did you mean '-enable-pre=3Dfalse'? >> *** Error code 1 >=20 > IIRC -enable-gvn=3Dfalse is a local option Dimitry added to our clang. = I don't > remember the suggested workaround off hand. = https://svnweb.freebsd.org/base/head/contrib/llvm/patches/patch-04-add-llv= m-gvn-option.diff?view=3Dco Alternatively, just skip building boot2, if you don't need it. -Dimitry --Apple-Mail=_C1AAB1AA-34BA-4704-BA5D-EAD715DA29E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlVcJTwACgkQsF6jCi4glqNBnACg+oKg0c/U9kCKSlXA4VAO3BUC 90UAoN8IPi0QGra/LPljjg5FLo7ey8Gz =XVHG -----END PGP SIGNATURE----- --Apple-Mail=_C1AAB1AA-34BA-4704-BA5D-EAD715DA29E4-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 16:10:56 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 950948FC; Wed, 20 May 2015 16:10:56 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 748F61E53; Wed, 20 May 2015 16:10:56 +0000 (UTC) Received: from [192.168.7.86] (wsip-98-172-74-163.ph.ph.cox.net [98.172.74.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8EB46193656; Wed, 20 May 2015 16:10:54 +0000 (UTC) Message-ID: <555CB20D.8040007@ignoranthack.me> Date: Wed, 20 May 2015 09:10:53 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dimitry Andric , Brooks Davis CC: "freebsd-hackers@freebsd.org" Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> <20150519202153.GB36377@spindle.one-eyed-alien.net> <555BE7A1.3040808@ignoranthack.me> <20150520045234.GA83978@spindle.one-eyed-alien.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:10:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/19/15 23:09, Dimitry Andric wrote: > On 20 May 2015, at 06:52, Brooks Davis wrote: >> >> On Tue, May 19, 2015 at 06:47:13PM -0700, Sean Bruno wrote: > ... >>> clang (LLVM option parsing): Unknown command line argument >>> '-enable-gvn=false'. Try: 'clang (LLVM option parsing) -help' >>> clang (LLVM option parsing): Did you mean '-enable-pre=false'? >>> *** Error code 1 >> >> IIRC -enable-gvn=false is a local option Dimitry added to our >> clang. I don't remember the suggested workaround off hand. > > https://svnweb.freebsd.org/base/head/contrib/llvm/patches/patch-04-add - -llvm-gvn-option.diff?view=co > > Alternatively, just skip building boot2, if you don't need it. > > -Dimitry > Should this be included upstream? sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVXLIKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k32AH/2JNbSWvfNF10MgWDSlaN35N gw6h5nbzsBqKkDDxXYEsct6FbfYIrVlHcf7t1VRwmWG6r18boMCZKlIdGgYhE8qH bdttIqng/h05gnb1HumDOxHFS+3EVApgY3SJjgSWwY2bLtIRuFPSvzcmwGKskNim Q1X7Ugp1oN1eNY/260vz07wwUVM+SF9BlCzfDdOCRiugypzej1Hpnt2TgJTqjHdB oFgmCgIMoVsl9C5+7wl04sOCYdslg7rT21Ebt0zrCTrt7+bCjQxb3FsryJN/po7j me9D1uQtnouxlipUSP0VC8dF2jn7xHipg33JM7YwuQWyZdJb16K0bcm7HBz9dYE= =CCU4 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 16:17:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C70AB67 for ; Wed, 20 May 2015 16:17:47 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 25FB51EA6 for ; Wed, 20 May 2015 16:17:47 +0000 (UTC) Received: by iebgx4 with SMTP id gx4so43012951ieb.0 for ; Wed, 20 May 2015 09:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jdgVPmhFOraU+aGucUEB34S32gwam8LrESiSPhhK574=; b=fH41zEqWeEN0Qak0pRvb2Uk9sqZncauhPSqQrviY2IFO+QOILAwbDWWT+lpFnumMaZ ZTrMNadGQu7myOlxS6i/L0vs8omIa2vJyL3EKkUYJK7XZyQ1GqYu4oO6p0xrWtP8/KJO 1KIYQNcgXMJR/geuMqflXamkgs6OoZrxFQsHKpTHkdY+MBm/AmYjAmGwTccdYX67//2I ovBZpoVsp7+R/M9JycOpE1KIXwlIHT/F3axjEI79v8sesbthmgbn0vGruIWKEg1aJMMJ 4B5NvoxCSxKt51t6hpAyQ4JprFVa1T0TCtygd08gcbOLuLa6Wr8ENOXEXjJ0WVRNDxS1 umlA== MIME-Version: 1.0 X-Received: by 10.50.79.232 with SMTP id m8mr28886332igx.6.1432138666508; Wed, 20 May 2015 09:17:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 20 May 2015 09:17:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2015 09:17:46 -0700 X-Google-Sender-Auth: dIvtDdYoUN4K7tZ7sQxtz6u-5_I Message-ID: Subject: Re: Trying to use clang/head and XCC From: Adrian Chadd To: NGie Cooper Cc: dave@sopwith.solgatos.com, "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:17:47 -0000 On 19 May 2015 at 17:50, NGie Cooper wrote: > On Tue, May 19, 2015 at 1:35 PM, Dave Seifert > wrote: >> sean typed: >>> No documentation of what CFLAGS are required to build and ignore warnings. >> >> Are you *sure* that ignoring those warnings is a good idea? > > The problem is that clang emits a *lot* of warnings with -Wall that > gcc doesn't, which causes failures if -Werror is enabled in the build > (annoying, but I've run into this at work...). Please see my earlier > reply about 10.0-RELEASE builds being broken on 11.0-CURRENT with > clang 3.6.0. > > Also, gcc emits different warnings because (IIRC) it analyzes code > that's been optimized whereas I believe clang does it beforehand > (please correct me if I'm wrong). I'm starting the process of finding/fixing issues that gcc-4.9.2 is finding/fixing on MIPS. It can only make things cleaner. I've also been bitten by the .. lack of clarity/sanity with how CFLAGS and such is populated. For MIPS, I discovered that: * there's stuff in kmod.*mk that sets -O and other flags, but it doesn't apply to normal kernel builds; and * the CFLAGS stuff in bsd.sys.mk is what's being paid attention to. Then we don't set the CPUTYPE stuff by default on MIPS, so I have to add CPUTYPE=mips32 or gcc-4.9.2 compiles mips1 code by default, which ends pretty hilariously in places. Fun times abound! -adrian From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 18:02:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61C43E61; Wed, 20 May 2015 18:02:39 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:0:20e:cff:fea0:e4a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B21B1FF0; Wed, 20 May 2015 18:02:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::fcb6:dce0:5147:d411] (unknown [IPv6:2001:7b8:3a7:0:fcb6:dce0:5147:d411]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C902423B7C; Wed, 20 May 2015 20:02:33 +0200 (CEST) Subject: Re: Trying to use clang/head and XCC Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5DEEEE1B-9B74-4D27-AE69-B274CE849E79"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <555CB20D.8040007@ignoranthack.me> Date: Wed, 20 May 2015 20:02:29 +0200 Cc: Brooks Davis , "freebsd-hackers@freebsd.org" Message-Id: <6DB19ADD-A18E-44BE-A3F7-936BB43F751B@FreeBSD.org> References: <555B638E.4020405@ignoranthack.me> <20150519165332.GA36377@spindle.one-eyed-alien.net> <555B91E8.9010309@ignoranthack.me> <20150519202153.GB36377@spindle.one-eyed-alien.net> <555BE7A1.3040808@ignoranthack.me> <20150520045234.GA83978@spindle.one-eyed-alien.net> <555CB20D.8040007@ignoranthack.me> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:02:39 -0000 --Apple-Mail=_5DEEEE1B-9B74-4D27-AE69-B274CE849E79 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 20 May 2015, at 18:10, Sean Bruno wrote: > > Signed PGP part > On 05/19/15 23:09, Dimitry Andric wrote: > > On 20 May 2015, at 06:52, Brooks Davis wrote: > >> > >> On Tue, May 19, 2015 at 06:47:13PM -0700, Sean Bruno wrote: > > ... > >>> clang (LLVM option parsing): Unknown command line argument > >>> '-enable-gvn=false'. Try: 'clang (LLVM option parsing) -help' > >>> clang (LLVM option parsing): Did you mean '-enable-pre=false'? > >>> *** Error code 1 > >> > >> IIRC -enable-gvn=false is a local option Dimitry added to our > >> clang. I don't remember the suggested workaround off hand. > > > > https://svnweb.freebsd.org/base/head/contrib/llvm/patches/patch-04-add > -llvm-gvn-option.diff?view=co > > > > Alternatively, just skip building boot2, if you don't need it. > > > > -Dimitry > > > > > Should this be included upstream? Possibly. I'll submit a review, and we'll see. -Dimitry --Apple-Mail=_5DEEEE1B-9B74-4D27-AE69-B274CE849E79 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlVczDkACgkQsF6jCi4glqPBVgCeITzK2YKPaJw0rSLip1nUxqA1 xN8Anj8A5Kln9Ics46dpuO/Qx7w/50Dq =0ujc -----END PGP SIGNATURE----- --Apple-Mail=_5DEEEE1B-9B74-4D27-AE69-B274CE849E79-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 18:10:09 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43F1822C for ; Wed, 20 May 2015 18:10:09 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 008A510C3 for ; Wed, 20 May 2015 18:10:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Yv8RS-0005Gr-Of for freebsd-hackers@freebsd.org; Wed, 20 May 2015 21:10:06 +0300 Date: Wed, 20 May 2015 21:10:06 +0300 From: Slawa Olhovchenkov To: freebsd-hackers@freebsd.org Subject: FreeBSD Boot Environments Message-ID: <20150520181006.GB21070@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:10:09 -0000 I am try to use Boot Environments and have some misundertanding. As I see beadm manage only zroot/ROOT. But base upgrade touch not only /{boot,etc,bin,lib,libexec,rescue,sbin} but also /usr and from time to time /var. And don't touch (at most) /root. What correct way to use Boot Environments? Rename zfs datasets as: From To zroot/usr zroot/ROOT/default/usr zroot/usr/home zroot/home create zroot/root leave (rename after moving zroot/usr) zroot/usr/ports zroot/usr/src zroot/usr/local Or somehow else? How prepare upgrades for such install? Create model setup, witch similar enviroment zfs snap modelroot@N do install{world,kernel} DESTDIR=/modelroot do mergemaster -I -U -D /modelroot zfs send -i N-1 modelroot@N | ssh host zfs recv zroot/ROOT/new Or somehow else? From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 18:26:31 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E5A862C for ; Wed, 20 May 2015 18:26:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBB712C8 for ; Wed, 20 May 2015 18:26:30 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 71400AB47E for ; Wed, 20 May 2015 18:26:24 +0000 (UTC) Message-ID: <555CD1DB.6010807@freebsd.org> Date: Wed, 20 May 2015 14:26:35 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Boot Environments References: <20150520181006.GB21070@zxy.spb.ru> In-Reply-To: <20150520181006.GB21070@zxy.spb.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ld62L0qTxpmwaObsH9DEgvsAtQIVlBn4k" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:26:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ld62L0qTxpmwaObsH9DEgvsAtQIVlBn4k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-20 14:10, Slawa Olhovchenkov wrote: > I am try to use Boot Environments and have some misundertanding. > As I see beadm manage only zroot/ROOT. But base upgrade touch not only > /{boot,etc,bin,lib,libexec,rescue,sbin} but also /usr and from time to > time /var. And don't touch (at most) /root. >=20 > What correct way to use Boot Environments? > Rename zfs datasets as: >=20 > From To > zroot/usr zroot/ROOT/default/usr > zroot/usr/home zroot/home >=20 > create >=20 > zroot/root >=20 > leave (rename after moving zroot/usr) >=20 > zroot/usr/ports > zroot/usr/src > zroot/usr/local >=20 > Or somehow else? >=20 > How prepare upgrades for such install? >=20 > Create model setup, witch similar enviroment > zfs snap modelroot@N > do install{world,kernel} DESTDIR=3D/modelroot > do mergemaster -I -U -D /modelroot > zfs send -i N-1 modelroot@N | ssh host zfs recv zroot/ROOT/new >=20 > Or somehow else? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 The typical way (done by bsdinstall) is that your zroot/usr dataset, is set 'canmount=3Doff', and only exists for you to create child datasets. Any files written to /usr/bin etc, actually end up going to the ROOT/default dataset you can tell by looking at 'zfs list' and your zroot/usr is only like 200kb, instead of 100s of megabytes. It also won't be listed in the output of 'mount'. --=20 Allan Jude --ld62L0qTxpmwaObsH9DEgvsAtQIVlBn4k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVXNHeAAoJEJrBFpNRJZKfdXUQALG33X3/DS/xVGAH4ntPQ+Ix JT9F4pE6XoaZthUXQo1K7lB5WNZSg6g62ThP/4BquIOh9EsZDoIFBLa2w77qu1rw gwYl7bU78moloacZpAEm9HI/y6kUvXOruP+bFGRjC9pTihx78VditqqBs/6nIaSs IXSGjvzj/nKbERunZdn8eeWU36fFvker1wvrNdPfD2dLGxw8i1/hZjGXfIRicZCV iW3OZSeXRPAkh+YMKc8bvB8E1Z1IGQmfU9iR3AxzgMELyAc1hD8YlssTfqzFghCN 639IN808W0LytvR32HQ3bL+i9kSMlTtRha3ynqpWwXgepQ+Tl7gLVAKmy2yAHV2q 1MdtnW+KQ95+4zf6raKCfieXUG8osbiq0rrbEK1RYZBjknxRN0nRy2D4/Woh+Jr1 OPzeP+3M+vk/VNme4eg2nb11SodVtXODqEzsJ9HKZFEQC5cA45dbUEMkjxhVcStm 0z1IZ4SRMu5hk4iYv6hrZT1f+e9htOvie8UsozCeTRi+XpuP1P9RFRd+RNfPh1Go aiGMpUo3/FgQNGlpujjKG2DFaj3ua95oOWp3CMh2BalrvPeJgk3G1FfcUjAuShHC rtpyRYGZ0jo4bswJOxUW6doaoobJZXa1KoyDDJ7CgSW76unmdJtDXK3sVA0rtA3w ZTPQvKdQQw60D2FU4rNr =QYzu -----END PGP SIGNATURE----- --ld62L0qTxpmwaObsH9DEgvsAtQIVlBn4k-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 19:16:16 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44953DF0; Wed, 20 May 2015 19:16:16 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 006061930; Wed, 20 May 2015 19:16:16 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Yv9TQ-0006NK-AM; Wed, 20 May 2015 22:16:12 +0300 Date: Wed, 20 May 2015 22:16:12 +0300 From: Slawa Olhovchenkov To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Boot Environments Message-ID: <20150520191612.GC21070@zxy.spb.ru> References: <20150520181006.GB21070@zxy.spb.ru> <555CD1DB.6010807@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555CD1DB.6010807@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:16:16 -0000 On Wed, May 20, 2015 at 02:26:35PM -0400, Allan Jude wrote: > On 2015-05-20 14:10, Slawa Olhovchenkov wrote: > > I am try to use Boot Environments and have some misundertanding. > > As I see beadm manage only zroot/ROOT. But base upgrade touch not only > > /{boot,etc,bin,lib,libexec,rescue,sbin} but also /usr and from time to > > time /var. And don't touch (at most) /root. > > > > What correct way to use Boot Environments? > > Rename zfs datasets as: > > > > From To > > zroot/usr zroot/ROOT/default/usr > > zroot/usr/home zroot/home > > > > create > > > > zroot/root > > > > leave (rename after moving zroot/usr) > > > > zroot/usr/ports > > zroot/usr/src > > zroot/usr/local > > > > Or somehow else? > > > > How prepare upgrades for such install? > > > > Create model setup, witch similar enviroment > > zfs snap modelroot@N > > do install{world,kernel} DESTDIR=/modelroot > > do mergemaster -I -U -D /modelroot > > zfs send -i N-1 modelroot@N | ssh host zfs recv zroot/ROOT/new > > > > Or somehow else? > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > The typical way (done by bsdinstall) is that your zroot/usr dataset, is > set 'canmount=off', and only exists for you to create child datasets. > > Any files written to /usr/bin etc, actually end up going to the > ROOT/default dataset > > you can tell by looking at 'zfs list' and your zroot/usr is only like > 200kb, instead of 100s of megabytes. It also won't be listed in the > output of 'mount'. Yes, I see. Thanks. What about creating zroot/root? What about send/recv? And how I can have localy changed /boot/loader.conf, /etc/rc.conf and other /etc/ files? From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 21:10:15 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E73C9491; Wed, 20 May 2015 21:10:15 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A537517B0; Wed, 20 May 2015 21:10:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::fcb6:dce0:5147:d411] (unknown [IPv6:2001:7b8:3a7:0:fcb6:dce0:5147:d411]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 38B6323DE2; Wed, 20 May 2015 23:10:12 +0200 (CEST) Subject: Re: FreeBSD Boot Environments Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_983AFBF5-1859-4E62-9403-02609A2FB026"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <555CD1DB.6010807@freebsd.org> Date: Wed, 20 May 2015 23:09:59 +0200 Cc: freebsd-hackers@freebsd.org Message-Id: <58BDAE4B-1929-427C-8E86-037E71AB0712@FreeBSD.org> References: <20150520181006.GB21070@zxy.spb.ru> <555CD1DB.6010807@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 21:10:16 -0000 --Apple-Mail=_983AFBF5-1859-4E62-9403-02609A2FB026 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 20 May 2015, at 20:26, Allan Jude wrote: > > On 2015-05-20 14:10, Slawa Olhovchenkov wrote: ... > > The typical way (done by bsdinstall) is that your zroot/usr dataset, is > set 'canmount=off', and only exists for you to create child datasets. > > Any files written to /usr/bin etc, actually end up going to the > ROOT/default dataset > > you can tell by looking at 'zfs list' and your zroot/usr is only like > 200kb, instead of 100s of megabytes. It also won't be listed in the > output of 'mount'. Just a minor note, the field to check is "refer", for example on one of my systems: $ zfs list zroot/usr NAME USED AVAIL REFER MOUNTPOINT zroot/usr 8.34G 404G 96K /usr E.g. all file systems *under* /usr together use 8.34G, but /usr itself only refers to 96K. -Dimitry --Apple-Mail=_983AFBF5-1859-4E62-9403-02609A2FB026 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlVc+DMACgkQsF6jCi4glqM/cwCdH0PV5/hD13yZvNl8wPd7LsYG zDcAnj5y0eB5NTqNvFeiOmpDSssqbPND =xT/7 -----END PGP SIGNATURE----- --Apple-Mail=_983AFBF5-1859-4E62-9403-02609A2FB026-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 01:07:07 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E4FD71B for ; Thu, 21 May 2015 01:07:07 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 2E03F1206 for ; Thu, 21 May 2015 01:07:06 +0000 (UTC) Received: from [10.12.77.4] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id A2D01193656 for ; Thu, 21 May 2015 01:06:58 +0000 (UTC) Message-ID: <555D2FB1.20208@ignoranthack.me> Date: Wed, 20 May 2015 18:06:57 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> In-Reply-To: <555B638E.4020405@ignoranthack.me> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 01:07:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/19/15 09:23, Sean Bruno wrote: > Following the External Tool Chain instructions on the wiki seem to > not work: https://wiki.freebsd.org/ExternalToolchain > > I've gotten about this far: > https://people.freebsd.org/~sbruno/clang_head_build_log.txt > > Two items of note. -- The bootstrap bits *completely* ignore XCC > and build with the host cc/c++ -- No documentation of what CFLAGS > are required to build and ignore warnings. > > Anyone out there have success doing this? > > sean _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > mmmm ... nice. >>> World build completed on Wed May 20 17:59:08 PDT 2015 sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVXS+uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k5QkIAMkTJiI6hx/ehlEGAB7ryVlb 7d7p49QYWbmtR47se7frUDnRIVmJJuGaeTfcXXYJyCO0Rtl12fjB6jTE5jk7+Qah M1VL6tYZc7yZcq71/dCIp2dkvDT7aPgavNfkoEdB14ZBT6Hes61a16Pm/bPocXm7 Xa81aNviuM0+yTrFQkHM+doyvV1YV96M3AavwojfISlVWcpdum5By5WrpRO1pjdB W1GebTEPClTWS/968WUAzqiczfDbwaj1nH8NcTW325fgIz0e4Jp7TNMeVy31nOmk SV2H2iBKsEbn5XHkitj/TBjTXFsXl2JbLHn1lsXiEMddSgthnIo/sFAmtqLgOKY= =euzI -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 01:26:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B6E097A for ; Thu, 21 May 2015 01:26:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.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 6E6B7141A for ; Thu, 21 May 2015 01:26:57 +0000 (UTC) Received: from [10.12.77.4] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 916CC193656 for ; Thu, 21 May 2015 01:26:56 +0000 (UTC) Message-ID: <555D3460.4060801@ignoranthack.me> Date: Wed, 20 May 2015 18:26:56 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Trying to use clang/head and XCC References: <555B638E.4020405@ignoranthack.me> <555D2FB1.20208@ignoranthack.me> In-Reply-To: <555D2FB1.20208@ignoranthack.me> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 01:26:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > > > mmmm ... nice. > >>>> World build completed on Wed May 20 17:59:08 PDT 2015 > > sean ah ... lovely .... >>> Kernel build for GENERIC completed on Wed May 20 18:25:18 PDT >>> 2015 sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVXTRbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ktUwIAKwQstiKtShZFIP1ZPjqVY5s 5dSCmaodO0/BsfZ0DpcUEzY4AqC8SPgeFmQAZfAo5dHu6XjepjvYHzLdBG4XIYUe 3O6R6FC0mCHLtKLApJuaSTfmL5oOQo20Es1xmSJYb2wpJ/ShWB3ivzwrUmQk9Ckx 9DTAocg17dgTlzZ3uUNk9ggH6FONPi3DmVbfCbzK8TFRY+//ybNKXR7f+u2NPam5 uVTnkyCBb/c44eBMbn7v7UK4j25bzJxwL209LhY6Qaxkl8P/gSUabDDhrDzHtvYU IHyB2ZfvqDprbdPJOjxJTY3x44FqnUnVcO0cXPfn2zyBFaACLnyIY/MN3GRgKCE= =Kl6T -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 06:53:43 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D973C8E; Thu, 21 May 2015 06:53:43 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 228131935; Thu, 21 May 2015 06:53:42 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1YvKAp-000KZ0-OF; Thu, 21 May 2015 09:41:43 +0300 From: Daniel Braniss Subject: OF_getprop weirdness - raspberry pi Date: Thu, 21 May 2015 09:41:42 +0300 Message-Id: Cc: current@freebsd.org To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 06:53:43 -0000 Hi, I=E2=80=99m running current as of last week on a raspberry pi B. i don=E2=80=99t know if this only related to arm, but this is what I = have in my rpi-b.dts: =E2=80=A6. spi0 { rfid0 { compatible =3D "rfid,mfrc5"; spi-chipselect =3D <0>; reset { compatible =3D "pcd-reset"; gpios =3D <&gpio 6 2>; }; lock { compatible =3D "lock-1"; gpios =3D <&gpio 13 2>; }; sense { compatible =3D "sense-1"; gpios =3D <&gpio 19 1>; };=20 }; =E2=80=A6 and a call to uint32_t data[3]; =09 OF_getprop(node, =E2=80=9Cgpios=E2=80=9D, data, sizeof(data)); = // node is =E2=80=98pcd-reset' returns: data[0]: 0x03000000 data[1]: 0x06000000 data[2]: 0x02000000 which looks to me that it=E2=80=99s in the wrong endian? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 13:05:10 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F4BA6CB for ; Thu, 21 May 2015 13:05:10 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AAF819C1 for ; Thu, 21 May 2015 13:05:09 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/afgnrylsiW+3ZjV+pQsJ X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-109-45-119-232.web.vodafone.de [109.45.119.232]) by smtp.strato.de (RZmta 37.6 DYNA|AUTH) with ESMTPSA id h058dar4LD4qVqn (using TLSv1 with cipher AES256-SHA (256 bits)) (Client did not present a certificate) for ; Thu, 21 May 2015 15:04:52 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Thu, 21 May 2015 15:04:51 +0200 Date: Thu, 21 May 2015 15:04:51 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Trying to use clang/head and XCC Message-ID: <20150521130451.GA2096@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:05:10 -0000 On Tue, May 19, 2015 at 05:50:29PM -0700, NGie Cooper wrote: > Also, gcc emits different warnings because (IIRC) it analyzes code > that's been optimized whereas I believe clang does it beforehand > (please correct me if I'm wrong). More like "clang provides the same set of warnings independent of the optimizer" vs "gcc warnings trigger depending on the phase of the moon". Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 14:25:47 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D36231CA for ; Thu, 21 May 2015 14:25:47 +0000 (UTC) Received: from pmta2.delivery4.ore.mailhop.org (pmta2.delivery4.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id B0952142F for ; Thu, 21 May 2015 14:25:47 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 21 May 2015 14:25:34 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4LEPdYq001317; Thu, 21 May 2015 08:25:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1432218339.1208.1.camel@freebsd.org> Subject: Re: OF_getprop weirdness - raspberry pi From: Ian Lepore To: Daniel Braniss Cc: hackers@freebsd.org, current@freebsd.org Date: Thu, 21 May 2015 08:25:39 -0600 In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:25:47 -0000 On Thu, 2015-05-21 at 09:41 +0300, Daniel Braniss wrote: > Hi, > I’m running current as of last week on a raspberry pi B. > > i don’t know if this only related to arm, but this is what I have in my rpi-b.dts: > …. > spi0 { > rfid0 { > compatible = "rfid,mfrc5"; > spi-chipselect = <0>; > reset { > compatible = "pcd-reset"; > gpios = <&gpio 6 2>; > }; > lock { > compatible = "lock-1"; > gpios = <&gpio 13 2>; > }; > sense { > compatible = "sense-1"; > gpios = <&gpio 19 1>; > }; > }; > … > and a call to > uint32_t data[3]; > > OF_getprop(node, “gpios”, data, sizeof(data)); // node is ‘pcd-reset' > returns: > data[0]: 0x03000000 > data[1]: 0x06000000 > data[2]: 0x02000000 > > which looks to me that it’s in the wrong endian? > > cheers, > danny FDT data is always big-endian, use OF_getencprop() to unpack it to host format. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 18:42:11 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B23A28A; Thu, 21 May 2015 18:42:11 +0000 (UTC) Received: from mail-vn0-x235.google.com (mail-vn0-x235.google.com [IPv6:2607:f8b0:400c:c0f::235]) (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 F294416AC; Thu, 21 May 2015 18:42:10 +0000 (UTC) Received: by vnbf1 with SMTP id f1so6612629vnb.2; Thu, 21 May 2015 11:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=/RzqSQO677fAj22aJUyJeaAQii+L3EV1LR75rUI2vCI=; b=uQMpD4LYNdihKO+A2tvqHNrL67x4zNylKuSQMFEKqJBn/7EDkxfRODmZ1kxWF2W1Z1 G0XzP2jrbhZXkDlBUWjbqw6+7TPGVlShgh6L0Ug2PyA7b0/HrF66eb3a1jhLtS1Teyt7 lVQQQzuw5brrHTTOEjG7Um44/8gGgKOmFvQ8uQoWrH2AULcJotoGhBRcdK4W0B7kjpLW iQG18NDzqVTg7W5URapkRwdGBPI0MwatmVGSA2L+MxVI1t/efQkqHGitA33FsBUp3Yla vEg1IvqCNfDjRDJEYTmRGg2zwW83XKSnx7FBb40HbMRg1To0QuBu8hIgv478aS+Ev29u Igxg== MIME-Version: 1.0 X-Received: by 10.52.60.227 with SMTP id k3mr3515047vdr.4.1432233729949; Thu, 21 May 2015 11:42:09 -0700 (PDT) Received: by 10.52.4.193 with HTTP; Thu, 21 May 2015 11:42:09 -0700 (PDT) Date: Thu, 21 May 2015 14:42:09 -0400 Message-ID: Subject: Botched NCQ on SSD - cannot disable? From: Neffi To: hackers@freebsd.org Cc: mav@freebsd.org, imp@freebsd.org X-Mailman-Approved-At: Thu, 21 May 2015 18:46:06 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:42:11 -0000 I was discussing this issue in freenode/#freebsd and I was recommended to shoot an email to you fellows about it. I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses Samsung's own controller from what I can gather. I had issues of mass data corruption when used under Linux, and several programs crashing unexpectedly when used under FreeBSD. I've gone through 2 drives under warranty with the same issue before customer service suggested to disable drive queuing. After some research it seems as though this drive (and several other common SSDs) report that they support NCQ, but in fact are botched and will have all sorts of problems with NCQ enabled ranging from poor performance, to I/O stalls to data corruption. Sure enough the logs on Linux spit out something along the lines of: > ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen > ata1.00: failed command: READ FPDMA QUEUED This happens several times when used on Linux, in the few hours leading up to total filesystem corruption. The recommendation in the Linux world is to disable NCQ on these drives, for which there is an easy boot-time tunable for it. This fixes the issue. No more data corruption. There doesn't seem to be a tunable for this anywhere on FreeBSD. camcontrol(8) mentions setting the tags used, but only between some hardcoded limits, with a default of 2 -- not sufficient to disable NCQ on the drive. It looks like presently the only option is to manually patch the quirks for this drive in the kernel and recompile before I can even install the system to the drive. From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 18:50:08 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45C754C2 for ; Thu, 21 May 2015 18:50:08 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 D94451747 for ; Thu, 21 May 2015 18:50:07 +0000 (UTC) Received: by wizk4 with SMTP id k4so24781366wiz.1 for ; Thu, 21 May 2015 11:50:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KqsgXa6//WGyzni4xD+dWl9FBvh9kbCx/W2TvrzYMdU=; b=e0wPPCo3RxvSc0183HPXhMfjKZpv3L5dKYyiQULby3ZQ6hCmxbNj+hscZcS79a2fDp ZXPmadxXYT9h8X6TOuN/peV3F0fr3ZnK4t8f5HJmWSEs6458oEVashDvH2IOAEDQ/BIl 6w9a/quHpMNkB3WpOpqv3mvqiCjNncGtTWdlSoXuHo+O3Bu4JRGUaFsctCxSoobgDLx5 SHNNMEYPFcQOrV2fjOnQWMvFhnf58Jb0/rYViV1GPymxPaLdYi4YnXQlk+O3YxRmnmix BkmVS4duNosqEPpjhh5nNLzP50dAb303MdidrNRjTikQUdMMVGqjVL557OBIN21hJTKR jB5A== X-Gm-Message-State: ALoCoQlS9mT+egoegPcuV6uCbKwlLmchB4QfKQ9e8TxnKA0cKPXLlIhd06LvtxJzQnorXhn2c9d+ X-Received: by 10.180.198.10 with SMTP id iy10mr301118wic.16.1432234200515; Thu, 21 May 2015 11:50:00 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ng5sm3894881wic.24.2015.05.21.11.49.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 11:49:59 -0700 (PDT) Message-ID: <555E28D1.2070600@multiplay.co.uk> Date: Thu, 21 May 2015 19:49:53 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Botched NCQ on SSD - cannot disable? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:50:08 -0000 We make extensive use of 840 EVO's attached to LSI controllers and never had an issue. What controller are you using? On 21/05/2015 19:42, Neffi wrote: > I was discussing this issue in freenode/#freebsd and I was recommended to > shoot an email to you fellows about it. > > I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses Samsung's > own controller from what I can gather. I had issues of mass data corruption > when used under Linux, and several programs crashing unexpectedly when used > under FreeBSD. I've gone through 2 drives under warranty with the same > issue before customer service suggested to disable drive queuing. > > After some research it seems as though this drive (and several other common > SSDs) report that they support NCQ, but in fact are botched and will have > all sorts of problems with NCQ enabled ranging from poor performance, to > I/O stalls to data corruption. > > Sure enough the logs on Linux spit out something along the lines of: > >> ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen >> ata1.00: failed command: READ FPDMA QUEUED > This happens several times when used on Linux, in the few hours leading up > to total filesystem corruption. > > The recommendation in the Linux world is to disable NCQ on these drives, > for which there is an easy boot-time tunable for it. This fixes the issue. > No more data corruption. > > There doesn't seem to be a tunable for this anywhere on FreeBSD. > camcontrol(8) mentions setting the tags used, but only between some > hardcoded limits, with a default of 2 -- not sufficient to disable NCQ on > the drive. It looks like presently the only option is to manually patch the > quirks for this drive in the kernel and recompile before I can even install > the system to the drive. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 18:54:31 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E14D766C for ; Thu, 21 May 2015 18:54:31 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 B4B2B1840 for ; Thu, 21 May 2015 18:54:31 +0000 (UTC) Received: by pabts4 with SMTP id ts4so114251638pab.3 for ; Thu, 21 May 2015 11:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FpmoRgyTX+HL5R4TROAsAaDg4N7UeLu2g5kwoXZVVMI=; b=CQWy2niGDwv2nHLfa9q+K8e5+dz0HVQMR3hJyFToDPyAeENupjkaNbS+BiAXrqW7LD qFs3UNGezvrAEgEh4YlYYaaT1uu6OhAZ08aKuqfSoH9tk0FfzqYmUgIkmw5C7z+1P6ii idIvpC78lHSH6VamJP3HnBDM/03xZoYeQVpDLgEafD0q4LvaMxlVsV/453GWsZYQwPwL SaTuMSlwrx2ft++cypZ0il29nzv81NjpunyvGg18bG3hIDADu7zJ1e9tEvQjiMUq86xe R41kgH6yTkfmzORaU3g02aBZ+mQ4vlYPBxjekHTzpvlli/9+CIb6hC1t8UmB/S8TeXww 0s9A== X-Gm-Message-State: ALoCoQkadTpPXGXEg9ShZ5KxMTY8xba9pSc1oX5bl41RRP3yHxuJKIoStrPdU97f3bXzbv4mSFES X-Received: by 10.68.57.142 with SMTP id i14mr8230426pbq.135.1432234465373; Thu, 21 May 2015 11:54:25 -0700 (PDT) Received: from [10.64.24.126] ([69.53.236.236]) by mx.google.com with ESMTPSA id do16sm20037568pac.15.2015.05.21.11.54.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 11:54:24 -0700 (PDT) Sender: Warner Losh Subject: Re: Botched NCQ on SSD - cannot disable? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F796935C-00AE-4B10-81D6-6CC27AFD50C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Thu, 21 May 2015 12:54:21 -0600 Cc: hackers@freebsd.org, mav@freebsd.org, imp@freebsd.org Message-Id: <8EDE2E6C-FED8-498B-9211-E3534A28D2FC@bsdimp.com> References: To: Neffi X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:54:32 -0000 --Apple-Mail=_F796935C-00AE-4B10-81D6-6CC27AFD50C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 21, 2015, at 12:42 PM, Neffi wrote: >=20 > I was discussing this issue in freenode/#freebsd and I was recommended = to shoot an email to you fellows about it. >=20 > I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses = Samsung's own controller from what I can gather. I had issues of mass = data corruption when used under Linux, and several programs crashing = unexpectedly when used under FreeBSD. I've gone through 2 drives under = warranty with the same issue before customer service suggested to = disable drive queuing. >=20 > After some research it seems as though this drive (and several other = common SSDs) report that they support NCQ, but in fact are botched and = will have all sorts of problems with NCQ enabled ranging from poor = performance, to I/O stalls to data corruption. >=20 > Sure enough the logs on Linux spit out something along the lines of: >=20 > > ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen > > ata1.00: failed command: READ FPDMA QUEUED >=20 > This happens several times when used on Linux, in the few hours = leading up to total filesystem corruption. >=20 > The recommendation in the Linux world is to disable NCQ on these = drives, for which there is an easy boot-time tunable for it. This fixes = the issue. No more data corruption. >=20 > There doesn't seem to be a tunable for this anywhere on FreeBSD. = camcontrol(8) mentions setting the tags used, but only between some = hardcoded limits, with a default of 2 -- not sufficient to disable NCQ = on the drive. It looks like presently the only option is to manually = patch the quirks for this drive in the kernel and recompile before I can = even install the system to the drive. One option is to use drives that don=E2=80=99t suck so bad. If you are using the AHCI controller, it has quirks for some cards that = don=E2=80=99t properly fill in the NCQ tags, but so far that=E2=80=99s a = tiny list of mostly older gear. What=E2=80=99s the host controller you = are using. Also, just because the command that hung on the drive is an NCQ command, = that doesn=E2=80=99t mean disabling NCQ commands will keep you safe. = That=E2=80=99s just the first one that=E2=80=99s issued after the = firmware wedges (or could be: that=E2=80=99s a very common scenario for = this kind of failure mode). There=E2=80=99s a quirk for the 840 EVO, but that=E2=80=99s just to = force 4k sector size. While I haven=E2=80=99t used this generation of Samsung SSDs, I=E2=80=99d = be highly surprised if this issue was really a problem in the drive = instead of some cabling issue, or other environmental issue leading the = the wedge. It=E2=80=99s true there=E2=80=99s no way to totally disable NCQ, but if = the drive is hanging with NCQ depth of 2, I=E2=80=99d be highly = surprised if it is actually NCQ causing this... Warner --Apple-Mail=_F796935C-00AE-4B10-81D6-6CC27AFD50C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVXindAAoJEGwc0Sh9sBEA3HoP/3NlsC66V2bPHoi+4GaxMi47 U+fsZ74aHCWi9MBShldNCYrM3umKDj126sMNSoAZaR1/Bd5y3vF55b+wHnd+Oc2P 7+mck+3PuexqtCq9lxhqPWpM5fIZ+3t/QfQus4qHbgBjajFIX+F21vqulC0BuE/m 5vw/QBKZ3hqaHZH7mHaY83vlNwzxpY0z5UHW8B2JFTJuVU7ixu2D9b6WcFM0Dd8a 92v4MeA47Hr6H3Kv9QzfprKs7MYV8Q67AM5qvZDitHIkFzwg8dFlSVe1KZCbyQox 7ia8JfnVhj8hPJlycC9Cc2xH78VJDML6yK9HruNuwy6TBobz6PgnYk7e1T5Kj62Y yk5IH2dQxdevMGZLNrl0SpuRzszJm6ukZOgmsrENC81wJ/EpiVuVYaBlWV7jLaxU NTtL2n7/MSVecHKi7MqgoHDg/JjpUmUnCiRitY77LiQSc/oA2cnVJREQtT1mMSWM NweaQsiJwNdjs2k1XUArop2mj+2PJSg8Zqzm5djq35F9iuRnXIX9WcgUvlvVWgLr BspdwtX1aaNDt9HRyrGFjBxrd19n2K4GsswCFNRzTy/18HQHhOuVRgUT6ai+8neK kYGgU1gvKQMe30/QMbBbpruJfMDyVgFayq862L74zjeqr956PpAar/nE61JNuId9 pwm9TfQIcUsV6yk7NPXB =BdTp -----END PGP SIGNATURE----- --Apple-Mail=_F796935C-00AE-4B10-81D6-6CC27AFD50C4-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 01:11:52 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87DF289C; Fri, 22 May 2015 01:11:52 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::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 57D121257; Fri, 22 May 2015 01:11:52 +0000 (UTC) Received: by pdfh10 with SMTP id h10so5201124pdf.3; Thu, 21 May 2015 18:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ll0L6ZmlhbkTt9w9py0CqTekPjg9OcpoR2koO+p57TU=; b=LqxEdEV7h61Cn0qaeoWaFRN33iCgOxcNrajG1jTFe620bse3RggEE4/XIC7Pgl7f7G d7TAzWLdQtam0oMplLgJDz90CPRimRZU8hGUtmANrV1++E29NnrCaSsglZybbNAZAnr+ QVxMn3pRbyRsVYeHzsQq7Ks77gPdoyncrBhhEaKSsJpqB3UIMWuIaImBCBxNjqWlSx8l v+t2ApxjYUN7Yc2ugR1BQGMF+iL7BctJTDiExvop4TKFq8aKfcafgN0pZmI+Sn32YMru bAubMc1Oca+KHHMDeTIbh6LtvpFBwYTRN/SB8FieH5Hz1DgbifuWRdn2NQikPr36K5Qt NT1A== X-Received: by 10.68.219.42 with SMTP id pl10mr10754384pbc.154.1432257111722; Thu, 21 May 2015 18:11:51 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([66.126.46.84]) by mx.google.com with ESMTPSA id c1sm292399pdc.45.2015.05.21.18.11.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 18:11:51 -0700 (PDT) Sender: Alexander Motin Message-ID: <555E8252.2060307@FreeBSD.org> Date: Fri, 22 May 2015 04:11:46 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Warner Losh , Neffi CC: hackers@freebsd.org, imp@freebsd.org Subject: Re: Botched NCQ on SSD - cannot disable? References: <8EDE2E6C-FED8-498B-9211-E3534A28D2FC@bsdimp.com> In-Reply-To: <8EDE2E6C-FED8-498B-9211-E3534A28D2FC@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:11:52 -0000 On 21.05.2015 21:54, Warner Losh wrote: > >> On May 21, 2015, at 12:42 PM, Neffi wrote: >> >> I was discussing this issue in freenode/#freebsd and I was >> recommended to shoot an email to you fellows about it. >> >> I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses >> Samsung's own controller from what I can gather. I had issues of >> mass data corruption when used under Linux, and several programs >> crashing unexpectedly when used under FreeBSD. I've gone through >> 2 drives under warranty with the same issue before customer >> service suggested to disable drive queuing. >> >> After some research it seems as though this drive (and several >> other common SSDs) report that they support NCQ, but in fact are >> botched and will have all sorts of problems with NCQ enabled >> ranging from poor performance, to I/O stalls to data corruption. >> >> Sure enough the logs on Linux spit out something along the lines >> of: >> >>> ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen >>> ata1.00: failed command: READ FPDMA QUEUED >> >> This happens several times when used on Linux, in the few hours >> leading up to total filesystem corruption. >> >> The recommendation in the Linux world is to disable NCQ on these >> drives, for which there is an easy boot-time tunable for it. This >> fixes the issue. No more data corruption. >> >> There doesn't seem to be a tunable for this anywhere on FreeBSD. >> camcontrol(8) mentions setting the tags used, but only between >> some hardcoded limits, with a default of 2 -- not sufficient to >> disable NCQ on the drive. It looks like presently the only option >> is to manually patch the quirks for this drive in the kernel and >> recompile before I can even install the system to the drive. > > One option is to use drives that don’t suck so bad. > > If you are using the AHCI controller, it has quirks for some cards > that don’t properly fill in the NCQ tags, but so far that’s a tiny > list of mostly older gear. What’s the host controller you are > using. > > Also, just because the command that hung on the drive is an NCQ > command, that doesn’t mean disabling NCQ commands will keep you > safe. That’s just the first one that’s issued after the firmware > wedges (or could be: that’s a very common scenario for this kind of > failure mode). > > There’s a quirk for the 840 EVO, but that’s just to force 4k sector > size. > > While I haven’t used this generation of Samsung SSDs, I’d be highly > surprised if this issue was really a problem in the drive instead > of some cabling issue, or other environmental issue leading the the > wedge. > > It’s true there’s no way to totally disable NCQ, but if the drive > is hanging with NCQ depth of 2, I’d be highly surprised if it is > actually NCQ causing this... IIRC camcontrol can disable NCQ, even though it is not very intuitive: `camcontrol negotiate adaX -T disable ; camcontrol reset ` -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 05:27:54 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1BBAD8E; Fri, 22 May 2015 05:27:54 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 2884C1BD7; Fri, 22 May 2015 05:27:53 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1YvfUY-000KTA-VI; Fri, 22 May 2015 08:27:31 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: OF_getprop weirdness - raspberry pi From: Daniel Braniss In-Reply-To: <1432218339.1208.1.camel@freebsd.org> Date: Fri, 22 May 2015 08:27:30 +0300 Cc: hackers@freebsd.org, current@freebsd.org Message-Id: <288BCD94-70F2-46B1-80F8-9755678E3D3F@cs.huji.ac.il> References: <1432218339.1208.1.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 05:27:54 -0000 > On May 21, 2015, at 5:25 PM, Ian Lepore wrote: >=20 > On Thu, 2015-05-21 at 09:41 +0300, Daniel Braniss wrote: >> Hi, >> I=E2=80=99m running current as of last week on a raspberry pi B. >>=20 >> i don=E2=80=99t know if this only related to arm, but this is what I = have in my rpi-b.dts: >> =E2=80=A6. >> spi0 { >> rfid0 { >> compatible =3D "rfid,mfrc5"; >> spi-chipselect =3D <0>; >> reset { >> compatible =3D "pcd-reset"; >> gpios =3D <&gpio 6 2>; >> }; >> lock { >> compatible =3D "lock-1"; >> gpios =3D <&gpio 13 2>; >> }; >> sense { >> compatible =3D "sense-1"; >> gpios =3D <&gpio 19 1>; >> };=20 >> }; >> =E2=80=A6 >> and a call to >> uint32_t data[3]; >> =09 >> OF_getprop(node, =E2=80=9Cgpios=E2=80=9D, data, sizeof(data)); = // node is =E2=80=98pcd-reset' >> returns: >> data[0]: 0x03000000 >> data[1]: 0x06000000 >> data[2]: 0x02000000 >>=20 >> which looks to me that it=E2=80=99s in the wrong endian? >>=20 >> cheers, >> danny >=20 > FDT data is always big-endian, use OF_getencprop() to unpack it to = host > format. >=20 thanks! is there (apart from the source), some man pages, doc? so far I found = outdated, or incomplete info. danny > -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat May 23 21:45:48 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F189296B for ; Sat, 23 May 2015 21:45:48 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 449661185 for ; Sat, 23 May 2015 21:45:48 +0000 (UTC) Received: from [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038] (unknown [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038]) (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 CD6102F5FA for ; Sat, 23 May 2015 21:45:40 +0000 (UTC) Message-ID: <5560F4FE.4030502@metricspace.net> Date: Sat, 23 May 2015 17:45:34 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: EFI ZFS loader successful load and boot Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5wXiKkjMGm8L5K77UST2Lh3U5c7DtNFJI" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 21:45:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5wXiKkjMGm8L5K77UST2Lh3U5c7DtNFJI Content-Type: multipart/mixed; boundary="------------010602090203020408050102" This is a multi-part message in MIME format. --------------010602090203020408050102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My work on ZFS support for EFI has now progressed to the point where I have successfully loaded and booted a kernel. The patch I have attached includes modifications to both boot1 and loader. The modified loader.efi can be loaded and run by boot1 or an appropriately-configured GRUB (I've tested with both). The code is not ready for integration; however, it is at this point ready for testing. The following need to be done, IMO, before it can be considered for integration: * boot1 completely ignores partition type GUIDs and probes everything. A notable effect of this are the "Not ufs" messages that show up. * There is some commented-out code for looking at command-line arguments in loader. It turns out I didn't need to do that. * I (ab)use the EFI pool allocator in a malloc-like fashion, allocating single objects in boot1. This might be OK, but someone with more EFI knowledge should probably comment as to whether or not it is. * A future refactoring project that might be useful would be to add a payload field to the end of struct devdesc, similar to what is done with struct sockaddr. That way, extended devdesc structures (like zfs_devdesc) could be handled in the same way that struct sockaddr_in, etc are. If you look at my code, there are a couple of places where I explicitly check for ZFS, and have separate branches that create zfs_devdesc's Please apply and test my patch with both UFS and ZFS filesystems. There is also one other issue, which I think is the fault of my hardware.= =2E. When I boot a kernel in EFI mode, it prints info about the EFI console, then the screen freezes. However, I can tell that the kernel and OS finish booting, because functions like suspend-on-lid-close and the power button work as normal after a while. However, when waking from suspend, the screen is just blank. This resembles an issue I've had with this particular laptop, which I've reported before on the ACPI list. Given this as well as basic common sense, I think it's extremely unlikely that this issue arises as a result of my modifications to loader. If anyone out there has a ZFS-based system and can confirm or deny this, that would be extremely useful information. Thanks, Eric --------------010602090203020408050102 Content-Type: text/x-patch; name="zfsefi.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfsefi.diff" Index: sys/boot/efi/boot1/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 --- sys/boot/efi/boot1/Makefile (revision 281381) +++ sys/boot/efi/boot1/Makefile (working copy) @@ -13,7 +13,7 @@ INTERNALPROG=3D =20 # architecture-specific loader code -SRCS=3D boot1.c reloc.c start.S +SRCS=3D boot1.c reloc.c start.S ufs_module.c zfs_module.c =20 CFLAGS+=3D -I. CFLAGS+=3D -I${.CURDIR}/../include @@ -20,6 +20,8 @@ CFLAGS+=3D -I${.CURDIR}/../include/${MACHINE_CPUARCH} CFLAGS+=3D -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+=3D -I${.CURDIR}/../../.. +CFLAGS+=3D -I${.CURDIR}/../../zfs/ +CFLAGS+=3D -I${.CURDIR}/../../../cddl/boot/zfs/ =20 # Always add MI sources and REGULAR efi loader bits .PATH: ${.CURDIR}/../loader/arch/${MACHINE_CPUARCH} Index: sys/boot/efi/boot1/boot1.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/boot1.c (revision 281381) +++ sys/boot/efi/boot1/boot1.c (working copy) @@ -5,6 +5,8 @@ * All rights reserved. * Copyright (c) 2014 Nathan Whitehorn * All rights reserved. + * Copyright (c) 2014 Eric McCorkle + * All rights reverved. * * Redistribution and use in source and binary forms are freely * permitted provided that the above copyright notice and this @@ -21,7 +23,6 @@ __FBSDID("$FreeBSD$"); =20 #include -#include #include #include =20 @@ -28,6 +29,8 @@ #include #include =20 +#include "boot_module.h" + #define _PATH_LOADER "/boot/loader.efi" #define _PATH_KERNEL "/boot/kernel/kernel" =20 @@ -41,14 +44,20 @@ u_int sp_size; }; =20 +static const boot_module_t* const boot_modules[] =3D +{ +#ifdef ZFS_EFI_BOOT + &zfs_module, +#endif +#ifdef UFS_EFI_BOOT + &ufs_module +#endif +}; + +#define NUM_BOOT_MODULES (sizeof(boot_modules) / sizeof(boot_module_t*))= + static const char digits[] =3D "0123456789abcdef"; =20 -static void panic(const char *fmt, ...) __dead2; -static int printf(const char *fmt, ...); -static int putchar(char c, void *arg); -static int vprintf(const char *fmt, va_list ap); -static int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap);= - static int __printf(const char *fmt, putc_func_t *putc, void *arg, va_li= st ap); static int __putc(char c, void *arg); static int __puts(const char *s, putc_func_t *putc, void *arg); @@ -62,9 +71,80 @@ static EFI_SYSTEM_TABLE *systab; static EFI_HANDLE *image; =20 -static void -bcopy(const void *src, void *dst, size_t len) + +void* Malloc(size_t len, const char* file, int line) { + void* out; + if (systab->BootServices->AllocatePool(EfiLoaderData, + len, &out) !=3D + EFI_SUCCESS) { + printf("Can't allocate memory pool\n"); + return NULL; + } + return out; +} + +char* strcpy(char* dst, const char* src) { + for(int i =3D 0; src[i]; i++) + dst[i] =3D src[i]; + + return dst; +} + +char* strchr(const char* s, int c) { + for(int i =3D 0; s[i]; i++) + if (s[i] =3D=3D c) + return (char*)(s + i); + + return NULL; +} + +int strncmp(const char *a, const char *b, size_t len) +{ + for (int i =3D 0; i < len; i++) + if(a[i] =3D=3D '\0' && b[i] =3D=3D '\0') { + return 0; + } else if(a[i] < b[i]) { + return -1; + } else if(a[i] > b[i]) { + return 1; + } + + return 0; +} + +char* strdup(const char* s) { + int len; + + for(len =3D 1; s[len]; len++); + + char* out =3D malloc(len); + + for(int i =3D 0; i < len; i++) + out[i] =3D s[i]; + + return out; +} + +int bcmp(const void *a, const void *b, size_t len) +{ + const char *sa =3D a; + const char *sb =3D b; + + for (int i =3D 0; i < len; i++) + if(sa[i] !=3D sb[i]) + return 1; + + return 0; +} + +int memcmp(const void *a, const void *b, size_t len) +{ + return bcmp(a, b, len); +} + +void bcopy(const void *src, void *dst, size_t len) +{ const char *s =3D src; char *d =3D dst; =20 @@ -72,23 +152,24 @@ *d++ =3D *s++; } =20 -static void -memcpy(void *dst, const void *src, size_t len) +void* memcpy(void *dst, const void *src, size_t len) { bcopy(src, dst, len); + return dst; } =20 -static void -bzero(void *b, size_t len) + +void* memset(void *b, int val, size_t len) { char *p =3D b; =20 while (len-- !=3D 0) - *p++ =3D 0; + *p++ =3D val; + + return b; } =20 -static int -strcmp(const char *s1, const char *s2) +int strcmp(const char *s1, const char *s2) { for (; *s1 =3D=3D *s2 && *s1; s1++, s2++) ; @@ -95,30 +176,99 @@ return ((u_char)*s1 - (u_char)*s2); } =20 +int putchr(char c, void *arg) +{ + CHAR16 buf[2]; + + if (c =3D=3D '\n') { + buf[0] =3D '\r'; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + } + buf[0] =3D c; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + return (1); +} + static EFI_GUID BlockIoProtocolGUID =3D BLOCK_IO_PROTOCOL; static EFI_GUID DevicePathGUID =3D DEVICE_PATH_PROTOCOL; +static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; static EFI_GUID LoadedImageGUID =3D LOADED_IMAGE_PROTOCOL; -static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; =20 -static EFI_BLOCK_IO *bootdev; -static EFI_DEVICE_PATH *bootdevpath; -static EFI_HANDLE *bootdevhandle; +#define MAX_DEVS 128 =20 -EFI_STATUS efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +void try_load(const boot_module_t* const mod, + const dev_info_t devs[], + size_t ndevs) { - EFI_HANDLE handles[128]; + int idx; + size_t bufsize; + void* const buffer =3D mod->load(devs, ndevs, _PATH_LOADER, &idx= , &bufsize); + EFI_HANDLE loaderhandle; + EFI_LOADED_IMAGE *loaded_image; + + if (NULL =3D=3D buffer) { + printf("Could not load file\n"); + return; + } + //printf("Loaded file %s, image at %p\n" + // "Attempting to load as bootable image...", + // _PATH_LOADER, image); + if (systab->BootServices->LoadImage(TRUE, image, devs[idx].devpa= th, + buffer, bufsize, &loaderhand= le) !=3D + EFI_SUCCESS) { + //printf("failed\n"); + return; + } + //printf("success\n" + // "Preparing to execute image..."); + + if (systab->BootServices->HandleProtocol(loaderhandle, + &LoadedImageGUID, + (VOID**)&loaded_image) = !=3D + EFI_SUCCESS) { + //printf("failed\n"); + return; + } + + //printf("success\n"); + + loaded_image->DeviceHandle =3D devs[idx].devhandle; + + //printf("Image prepared, attempting to execute\n"); + // XXX Set up command args first + if (systab->BootServices->StartImage(loaderhandle, NULL, NULL) != =3D + EFI_SUCCESS) { + //printf("Failed to execute loader\n"); + return; + } + //printf("Shouldn't be here!\n"); +} + +void efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +{ + EFI_HANDLE handles[MAX_DEVS]; + dev_info_t module_devs[NUM_BOOT_MODULES][MAX_DEVS]; + size_t dev_offsets[NUM_BOOT_MODULES]; EFI_BLOCK_IO *blkio; - UINTN i, nparts =3D sizeof(handles), cols, rows, max_dim, best_mode; + UINTN nparts =3D sizeof(handles); EFI_STATUS status; EFI_DEVICE_PATH *devpath; EFI_BOOT_SERVICES *BS; EFI_CONSOLE_CONTROL_PROTOCOL *ConsoleControl =3D NULL; SIMPLE_TEXT_OUTPUT_INTERFACE *conout =3D NULL; - char *path =3D _PATH_LOADER; =20 + // Basic initialization systab =3D Xsystab; image =3D Ximage; =20 + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + dev_offsets[i] =3D 0; + } + + // Set up the console, so printf works. BS =3D systab->BootServices; status =3D BS->LocateProtocol(&ConsoleControlGUID, NULL, (VOID **)&ConsoleControl); @@ -128,10 +278,14 @@ /* * Reset the console and find the best text mode. */ + UINTN max_dim; + UINTN best_mode; + UINTN cols; + UINTN rows; conout =3D systab->ConOut; conout->Reset(conout, TRUE); max_dim =3D best_mode =3D 0; - for (i =3D 0; ; i++) { + for (int i =3D 0; ; i++) { status =3D conout->QueryMode(conout, i, &cols, &rows); if (EFI_ERROR(status)) @@ -141,6 +295,7 @@ best_mode =3D i; } } + if (max_dim > 0) conout->SetMode(conout, best_mode); conout->EnableCursor(conout, TRUE); @@ -147,206 +302,94 @@ conout->ClearScreen(conout); =20 printf("\n" - ">> FreeBSD EFI boot block\n"); - printf(" Loader path: %s\n", path); + ">> FreeBSD ZFS-enabled EFI boot block\n"); + printf(" Loader path: %s\n\n", _PATH_LOADER); =20 + printf(" Initializing modules:"); + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D boot_modules[i]) + { + printf(" %s", boot_modules[i]->name); + boot_modules[i]->init(image, systab, BS); + } + } + putchr('\n', NULL); + + // Get all the device handles status =3D systab->BootServices->LocateHandle(ByProtocol, &BlockIoProtocolGUID, NULL, &nparts, handles); nparts /=3D sizeof(handles[0]); + //printf(" Scanning %lu device handles\n", nparts); =20 - for (i =3D 0; i < nparts; i++) { + // Scan all partitions, probing with all modules. + for (int i =3D 0; i < nparts; i++) { + dev_info_t devinfo; + + // Figure out if we're dealing with an actual partition status =3D systab->BootServices->HandleProtocol(handles[i], &DevicePathGUID, (void **)&devpath); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a device path protocol\n")= ; continue; + } =20 - while (!IsDevicePathEnd(NextDevicePathNode(devpath))) + while (!IsDevicePathEnd(NextDevicePathNode(devpath))) { + //printf(" Advancing to next device\n"); devpath =3D NextDevicePathNode(devpath); + } =20 status =3D systab->BootServices->HandleProtocol(handles[i], &BlockIoProtocolGUID, (void **)&blkio); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a block device\n"); continue; + } =20 - if (!blkio->Media->LogicalPartition) + if (!blkio->Media->LogicalPartition) { + //printf(" Logical partition\n"); continue; + } =20 - if (domount(devpath, blkio, 1) >=3D 0) - break; - } + // Setup devinfo + devinfo.dev =3D blkio; + devinfo.devpath =3D devpath; + devinfo.devhandle =3D handles[i]; + devinfo.devdata =3D NULL; =20 - if (i =3D=3D nparts) - panic("No bootable partition found"); - - bootdevhandle =3D handles[i]; - load(path); - - panic("Load failed"); - - return EFI_SUCCESS; -} - -static int -dskread(void *buf, u_int64_t lba, int nblk) -{ - EFI_STATUS status; - int size; - - lba =3D lba / (bootdev->Media->BlockSize / DEV_BSIZE); - size =3D nblk * DEV_BSIZE; - status =3D bootdev->ReadBlocks(bootdev, bootdev->Media->MediaId, lba, - size, buf); - - if (EFI_ERROR(status)) - return (-1); - - return (0); -} - -#include "ufsread.c" - -static ssize_t -fsstat(ufs_ino_t inode) -{ -#ifndef UFS2_ONLY - static struct ufs1_dinode dp1; - ufs1_daddr_t addr1; -#endif -#ifndef UFS1_ONLY - static struct ufs2_dinode dp2; -#endif - static struct fs fs; - static ufs_ino_t inomap; - char *blkbuf; - void *indbuf; - size_t n, nb, size, off, vboff; - ufs_lbn_t lbn; - ufs2_daddr_t addr2, vbaddr; - static ufs2_daddr_t blkmap, indmap; - u_int u; - - blkbuf =3D dmadat->blkbuf; - indbuf =3D dmadat->indbuf; - if (!dsk_meta) { - inomap =3D 0; - for (n =3D 0; sblock_try[n] !=3D -1; n++) { - if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, - SBLOCKSIZE / DEV_BSIZE)) - return -1; - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (( -#if defined(UFS1_ONLY) - fs.fs_magic =3D=3D FS_UFS1_MAGIC -#elif defined(UFS2_ONLY) - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#else - fs.fs_magic =3D=3D FS_UFS1_MAGIC || - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#endif - ) && - fs.fs_bsize <=3D MAXBSIZE && - fs.fs_bsize >=3D sizeof(struct fs)) - break; - } - if (sblock_try[n] =3D=3D -1) { - printf("Not ufs\n"); - return -1; - } - dsk_meta++; - } else - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (!inode) - return 0; - if (inomap !=3D inode) { - n =3D IPERVBLK(&fs); - if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) - return -1; - n =3D INO_TO_VBO(n, inode); -#if defined(UFS1_ONLY) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); -#elif defined(UFS2_ONLY) - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#else - if (fs.fs_magic =3D=3D FS_UFS1_MAGIC) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); - else - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#endif - inomap =3D inode; - fs_off =3D 0; - blkmap =3D indmap =3D 0; + // Run through each module, see if it can load this part= ition + for (int j =3D 0; j < NUM_BOOT_MODULES; j++ ) + { + if (NULL !=3D boot_modules[j] && + boot_modules[j]->probe(&devinfo)) + { + // If it can, save it to the device list= for + // that module + module_devs[j][dev_offsets[j]++] =3D dev= info; + } + } } - size =3D DIP(di_size); - n =3D size - fs_off; - return (n); -} =20 -static struct dmadat __dmadat; + // Select a partition to boot. We do this by trying each + // module in order. + for (int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D boot_modules[i]) + { + //printf(" Trying to load from %lu %s partitio= ns\n", + // dev_offsets[i], boot_modules[i]->name);= + try_load(boot_modules[i], module_devs[i], + dev_offsets[i]); + //printf(" Failed\n"); + } + } =20 -static int -domount(EFI_DEVICE_PATH *device, EFI_BLOCK_IO *blkio, int quiet) -{ - - dmadat =3D &__dmadat; - bootdev =3D blkio; - bootdevpath =3D device; - if (fsread(0, NULL, 0)) { - if (!quiet) - printf("domount: can't read superblock\n"); - return (-1); - } - if (!quiet) - printf("Succesfully mounted UFS filesystem\n"); - return (0); + // If we get here, we're out of luck... + panic("No bootable partitions found!"); } =20 -static void -load(const char *fname) +void panic(const char *fmt, ...) { - ufs_ino_t ino; - EFI_STATUS status; - EFI_HANDLE loaderhandle; - EFI_LOADED_IMAGE *loaded_image; - void *buffer; - size_t bufsize; - - if ((ino =3D lookup(fname)) =3D=3D 0) { - printf("File %s not found\n", fname); - return; - } - - bufsize =3D fsstat(ino); - status =3D systab->BootServices->AllocatePool(EfiLoaderData, - bufsize, &buffer); - fsread(ino, buffer, bufsize); - - /* XXX: For secure boot, we need our own loader here */ - status =3D systab->BootServices->LoadImage(TRUE, image, bootdevpath, - buffer, bufsize, &loaderhandle); - if (EFI_ERROR(status)) - printf("LoadImage failed with error %lx\n", status); - - status =3D systab->BootServices->HandleProtocol(loaderhandle, - &LoadedImageGUID, (VOID**)&loaded_image); - if (EFI_ERROR(status)) - printf("HandleProtocol failed with error %lx\n", status); - - loaded_image->DeviceHandle =3D bootdevhandle; - - status =3D systab->BootServices->StartImage(loaderhandle, NULL, NULL); - if (EFI_ERROR(status)) - printf("StartImage failed with error %lx\n", status); -} - -static void -panic(const char *fmt, ...) -{ char buf[128]; va_list ap; =20 @@ -358,50 +401,25 @@ while (1) {} } =20 -static int -printf(const char *fmt, ...) +int printf(const char *fmt, ...) { va_list ap; int ret; =20 - /* Don't annoy the user as we probe for partitions */ - if (strcmp(fmt,"Not ufs\n") =3D=3D 0) - return 0; =20 va_start(ap, fmt); - ret =3D vprintf(fmt, ap); + ret =3D __printf(fmt, putchr, 0, ap); va_end(ap); return (ret); } =20 -static int -putchar(char c, void *arg) +void vprintf(const char *fmt, va_list ap) { - CHAR16 buf[2]; - - if (c =3D=3D '\n') { - buf[0] =3D '\r'; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - } - buf[0] =3D c; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - return (1); + __printf(fmt, putchr, 0, ap); } =20 -static int -vprintf(const char *fmt, va_list ap) +int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) { - int ret; - - ret =3D __printf(fmt, putchar, 0, ap); - return (ret); -} - -static int -vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) -{ struct sp_data sp; int ret; =20 Index: sys/boot/efi/boot1/boot_module.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/boot_module.h (revision 0) +++ sys/boot/efi/boot1/boot_module.h (working copy) @@ -0,0 +1,60 @@ +#ifndef _BOOT_MODULE_H_ +#define _BOOT_MODULE_H_ + +#include + +#include +#include +#include + +#define UFS_EFI_BOOT 1 +#define ZFS_EFI_BOOT 1 + +// EFI device info +typedef struct dev_info_t +{ + EFI_BLOCK_IO *dev; + EFI_DEVICE_PATH *devpath; + EFI_HANDLE *devhandle; + void *devdata; +} dev_info_t; + +// A boot loader module. This is a standard interface for filesystem +// modules in the EFI system. +typedef struct boot_module_t +{ + const char* const name; + + // Initialize the module. + void (* const init)(EFI_HANDLE image, + EFI_SYSTEM_TABLE* systab, + EFI_BOOT_SERVICES *bootsrv); + + // Check to see if curr_dev is a device that this module can han= dle. + bool (* const probe)(dev_info_t* dev); + + // Select the best out of a set of devices that probe indicated = were + // loadable, and load it. + void* (* const load)(const dev_info_t devs[], + size_t ndevs, + const char* loader_path, + int* idxref, + size_t* bufsizeref); +} boot_module_t; + +// Standard boot modules +#ifdef UFS_EFI_BOOT +extern const boot_module_t ufs_module; +#endif +#ifdef ZFS_EFI_BOOT +extern const boot_module_t zfs_module; +#endif + +// Functions available to modules +extern int strcmp(const char *s1, const char *s2); +extern void bcopy(const void *src, void *dst, size_t len); +extern void panic(const char *fmt, ...) __dead2; +extern int printf(const char *fmt, ...); +extern int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap);= + +#endif Property changes on: sys/boot/efi/boot1/boot_module.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/ufs_module.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/ufs_module.c (revision 0) +++ sys/boot/efi/boot1/ufs_module.c (working copy) @@ -0,0 +1,210 @@ +/*- + * Copyright (c) 1998 Robert Nordier + * All rights reserved. + * Copyright (c) 2001 Robert Drehmel + * All rights reserved. + * Copyright (c) 2014 Nathan Whitehorn + * All rights reserved. + * Copyright (c) 2015 Eric McCorkle + * All rights reverved. + * + * Redistribution and use in source and binary forms are freely + * permitted provided that the above copyright notice and this + * paragraph and the following disclaimer are duplicated in all + * such forms. + * + * This software is provided "AS IS" and without any express or + * implied warranties, including, without limitation, the implied + * warranties of merchantability and fitness for a particular + * purpose. + */ +#include +#include + +#include +#include + +#include + +#include "boot_module.h" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; +static dev_info_t devinfo; +static EFI_GUID LoadedImageGUID =3D LOADED_IMAGE_PROTOCOL; + +static int +dskread(void *buf, u_int64_t lba, int nblk) +{ + EFI_STATUS status; + int size; + + lba =3D lba / (devinfo.dev->Media->BlockSize / DEV_BSIZE); + size =3D nblk * DEV_BSIZE; + status =3D devinfo.dev->ReadBlocks(devinfo.dev, + devinfo.dev->Media->MediaId, lb= a, + size, buf); + + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +#include "ufsread.c" + +static ssize_t +fsstat(ufs_ino_t inode) +{ +#ifndef UFS2_ONLY + static struct ufs1_dinode dp1; + ufs1_daddr_t addr1; +#endif +#ifndef UFS1_ONLY + static struct ufs2_dinode dp2; +#endif + static struct fs fs; + static ufs_ino_t inomap; + char *blkbuf; + void *indbuf; + size_t n, nb, size, off, vboff; + ufs_lbn_t lbn; + ufs2_daddr_t addr2, vbaddr; + static ufs2_daddr_t blkmap, indmap; + u_int u; + + blkbuf =3D dmadat->blkbuf; + indbuf =3D dmadat->indbuf; + if (!dsk_meta) { + inomap =3D 0; + for (n =3D 0; sblock_try[n] !=3D -1; n++) { + if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, + SBLOCKSIZE / DEV_BSIZE)) + return -1; + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (( +#if defined(UFS1_ONLY) + fs.fs_magic =3D=3D FS_UFS1_MAGIC +#elif defined(UFS2_ONLY) + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#else + fs.fs_magic =3D=3D FS_UFS1_MAGIC || + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#endif + ) && + fs.fs_bsize <=3D MAXBSIZE && + fs.fs_bsize >=3D sizeof(struct fs)) + break; + } + if (sblock_try[n] =3D=3D -1) { + return -1; + } + dsk_meta++; + } else + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (!inode) + return 0; + if (inomap !=3D inode) { + n =3D IPERVBLK(&fs); + if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) + return -1; + n =3D INO_TO_VBO(n, inode); +#if defined(UFS1_ONLY) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); +#elif defined(UFS2_ONLY) + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#else + if (fs.fs_magic =3D=3D FS_UFS1_MAGIC) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); + else + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#endif + inomap =3D inode; + fs_off =3D 0; + blkmap =3D indmap =3D 0; + } + size =3D DIP(di_size); + n =3D size - fs_off; + return (n); +} + +static struct dmadat __dmadat; + +static bool +probe(dev_info_t* const dev) +{ + devinfo =3D *dev; + dmadat =3D &__dmadat; + if (fsread(0, NULL, 0)) { + return 0; + } + return 1; +} + +static void* +try_load(const dev_info_t dev, + const char* const loader_path, + size_t* const bufsizeref) +{ + ufs_ino_t ino; + EFI_STATUS status; + void *buffer; + size_t bufsize; + + devinfo =3D dev; + if ((ino =3D lookup(loader_path)) =3D=3D 0) { + printf("File %s not found\n", loader_path); + return NULL; + } + + bufsize =3D fsstat(ino); + *bufsizeref =3D bufsize; + status =3D systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer); + fsread(ino, buffer, bufsize); + return buffer; +} + +static void* +load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) + { + void* const out =3D try_load(devs[i], loader_path, bufsiz= eref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; +} + +const boot_module_t ufs_module =3D +{ + .name =3D "UFS", + .init =3D init, + .probe =3D probe, + .load =3D load +}; Property changes on: sys/boot/efi/boot1/ufs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/zfs_module.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/zfs_module.c (revision 0) +++ sys/boot/efi/boot1/zfs_module.c (working copy) @@ -0,0 +1,201 @@ +/* Copyright (c) 2015 Eric McCorkle. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * 3. Neither the name of the author nor the names of any contributors + * may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ +#include +#include +#include + +#include +#include +#include + +#include + +#include "boot_module.h" + +#include "libzfs.h" +#include "zfsimpl.c" + +#define PATH_CONFIG "/boot/config" +#define PATH_DOTCONFIG "/boot/.config" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; + +static int +vdev_read(vdev_t * const vdev, + void * const priv, + const off_t off, + void * const buf, + const size_t bytes) +{ + const dev_info_t* const devinfo =3D (const dev_info_t*) priv; + const off_t lba =3D off / devinfo->dev->Media->BlockSize; + const EFI_STATUS status =3D + devinfo->dev->ReadBlocks(devinfo->dev, + devinfo->dev->Media->MediaId, + lba, bytes, buf); + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +static bool probe(dev_info_t* const dev) +{ + spa_t* spa; + int result =3D vdev_probe(vdev_read, dev, &spa); + dev->devdata =3D spa; + + return result =3D=3D 0; +} + +static void* try_load(const dev_info_t devinfo, + const char* const loader_path, + size_t* const bufsizeref) +{ + spa_t *spa =3D devinfo.devdata; + struct zfsmount zfsmount; + dnode_phys_t dn; + bool autoboot =3D true; + + if (zfs_spa_init(spa) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + // First, try mounting the ZFS volume + if (zfs_mount(spa, 0, &zfsmount) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + //vdev_t * const primary_vdev =3D spa_get_primary_vdev(spa); + + if (zfs_lookup(&zfsmount, loader_path, &dn) !=3D 0) { + return NULL; + } + + struct stat st; + if (zfs_dnode_stat(spa, &dn, &st)) { + return NULL; + } + + const size_t bufsize =3D st.st_size; + void* buffer; + EFI_STATUS status; + + *bufsizeref =3D bufsize; + + if (systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer) !=3D + EFI_SUCCESS) { + return NULL; + } + + if (dnode_read(spa, &dn, 0, buffer, bufsize) < 0) { + return NULL; + } + + return buffer; +} + +static int zfs_mount_ds(const char * const dsname, + struct zfsmount * const zfsmount, + spa_t ** const spa) +{ + uint64_t newroot; + spa_t *newspa; + char *q; + + q =3D strchr(dsname, '/'); + if (q) + *q++ =3D '\0'; + newspa =3D spa_find_by_name(dsname); + if (newspa =3D=3D NULL) { + printf("\nCan't find ZFS pool %s\n", dsname); + return -1; + } + + if (zfs_spa_init(newspa)) + return -1; + + newroot =3D 0; + if (q) { + if (zfs_lookup_dataset(newspa, q, &newroot)) { + printf("\nCan't find dataset %s in ZFS pool %s\n= ", + q, newspa->spa_name); + return -1; + } + } + if (zfs_mount(newspa, newroot, zfsmount)) { + printf("\nCan't mount ZFS dataset\n"); + return -1; + } + *spa =3D newspa; + return (0); +} + +static void* load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) { + void* const out =3D try_load(devs[i], loader_path, bufsi= zeref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; + zfs_init(); +} + +const boot_module_t zfs_module =3D +{ + .name =3D "ZFS", + .init =3D init, + .probe =3D probe, + .load =3D load +}; Property changes on: sys/boot/efi/boot1/zfs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/include/efilib.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/include/efilib.h (revision 281381) +++ sys/boot/efi/include/efilib.h (working copy) @@ -43,7 +43,8 @@ =20 int efi_register_handles(struct devsw *, EFI_HANDLE *, EFI_HANDLE *, int= ); EFI_HANDLE efi_find_handle(struct devsw *, int); -int efi_handle_lookup(EFI_HANDLE, struct devsw **, int *); +void efi_handle_update_dev(EFI_HANDLE, struct devsw *, int, uint64_t); +int efi_handle_lookup(EFI_HANDLE, struct devsw **, int *, uint64_t *); =20 int efi_status_to_errno(EFI_STATUS); time_t efi_time(EFI_TIME *); Index: sys/boot/efi/libefi/handles.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/libefi/handles.c (revision 281381) +++ sys/boot/efi/libefi/handles.c (working copy) @@ -35,6 +35,7 @@ EFI_HANDLE alias; struct devsw *dev; int unit; + uint64_t extra; }; =20 struct entry *entry; @@ -78,8 +79,28 @@ return (NULL); } =20 +void efi_handle_update_dev(const EFI_HANDLE handle, + struct devsw * const dev, + int unit, + uint64_t guid) +{ + int idx; + + for (idx =3D 0; idx < nentries; idx++) { + if (entry[idx].handle !=3D handle) + continue; + entry[idx].dev =3D dev; + entry[idx].unit =3D unit; + entry[idx].alias =3D NULL; + entry[idx].extra =3D guid; + } +} + int -efi_handle_lookup(EFI_HANDLE h, struct devsw **dev, int *unit) +efi_handle_lookup(EFI_HANDLE h, + struct devsw **dev, + int *unit, + uint64_t *extra) { int idx; =20 @@ -90,6 +111,8 @@ *dev =3D entry[idx].dev; if (unit !=3D NULL) *unit =3D entry[idx].unit; + if (extra !=3D NULL) + *extra =3D entry[idx].extra; return (0); } return (ENOENT); Index: sys/boot/efi/loader/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 --- sys/boot/efi/loader/Makefile (revision 281381) +++ sys/boot/efi/loader/Makefile (working copy) @@ -12,6 +12,8 @@ PROG=3D loader.sym INTERNALPROG=3D =20 +#LIBZFSBOOT=3D ${.OBJDIR}/../../zfs/libzfsboot.a + .PATH: ${.CURDIR}/../../efi/loader # architecture-specific loader code SRCS=3D autoload.c \ @@ -21,7 +23,8 @@ devicename.c \ main.c \ smbios.c \ - vers.c + vers.c \ + zfs.c =20 .PATH: ${.CURDIR}/arch/${MACHINE_CPUARCH} # For smbios.c @@ -36,6 +39,8 @@ CFLAGS+=3D -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+=3D -I${.CURDIR}/../../.. CFLAGS+=3D -I${.CURDIR}/../../i386/libi386 +CFLAGS+=3D -I${.CURDIR}/../../zfs +CFLAGS+=3D -I${.CURDIR}/../../../cddl/boot/zfs CFLAGS+=3D -DNO_PCI -DEFI =20 .if ${MK_FORTH} !=3D "no" @@ -62,7 +67,7 @@ CFLAGS+=3D -DEFI_STAGING_SIZE=3D${EFI_STAGING_SIZE} .endif =20 -# Always add MI sources=20 +# Always add MI sources .PATH: ${.CURDIR}/../../common .include "${.CURDIR}/../../common/Makefile.inc" CFLAGS+=3D -I${.CURDIR}/../../common @@ -73,7 +78,7 @@ LDSCRIPT=3D ${.CURDIR}/arch/${MACHINE_CPUARCH}/ldscript.${MACHINE_CPUARC= H} LDFLAGS=3D -Wl,-T${LDSCRIPT} -Wl,-Bsymbolic -shared -Wl,-znocombreloc =20 -CLEANFILES=3D vers.c loader.efi +CLEANFILES=3D vers.c loader.efi zfs.c =20 NEWVERSWHAT=3D "EFI loader" ${MACHINE_CPUARCH} =20 @@ -80,6 +85,9 @@ vers.c: ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/../../efi/loader/v= ersion sh ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version ${NEWVERSWHAT}= =20 +zfs.c: + cp ${.CURDIR}/../../zfs/zfs.c ${.CURDIR} + OBJCOPY?=3D objcopy OBJDUMP?=3D objdump =20 @@ -103,9 +111,9 @@ =20 LIBEFI=3D ${.OBJDIR}/../libefi/libefi.a =20 -DPADD=3D ${LIBFICL} ${LIBEFI} ${LIBFDT} ${LIBEFI_FDT} ${LIBSTAND} \ +DPADD=3D ${LIBFICL} ${LIBEFI} ${LIBFDT} ${LIBEFI_FDT} ../../../../lib/l= ibstand/libstand.a \ ${LDSCRIPT} -LDADD=3D ${LIBFICL} ${LIBEFI} ${LIBFDT} ${LIBEFI_FDT} ${LIBSTAND} +LDADD=3D ${LIBFICL} ${LIBEFI} ${LIBFDT} ${LIBEFI_FDT} ../../../../lib/l= ibstand/libstand.a =20 .endif # ${COMPILER_TYPE} !=3D "gcc" =20 Index: sys/boot/efi/loader/conf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/conf.c (revision 281381) +++ sys/boot/efi/loader/conf.c (working copy) @@ -31,14 +31,17 @@ #include #include #include +#include "../zfs/libzfs.h" =20 struct devsw *devsw[] =3D { &efipart_dev, &efinet_dev, + &zfs_dev, NULL }; =20 struct fs_ops *file_system[] =3D { + &zfs_fsops, &dosfs_fsops, &ufs_fsops, &cd9660_fsops, Index: sys/boot/efi/loader/devicename.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/devicename.c (revision 281381) +++ sys/boot/efi/loader/devicename.c (working copy) @@ -32,6 +32,7 @@ #include #include #include "bootstrap.h" +#include "libzfs.h" =20 #include #include @@ -38,7 +39,7 @@ =20 static int efi_parsedev(struct devdesc **, const char *, const char **);= =20 -/*=20 +/* * Point (dev) at an allocated device specifier for the device matching = the * path in (devspec). If it contains an explicit device specification, * use that. If not, use the default device. @@ -48,7 +49,6 @@ { struct devdesc **dev =3D (struct devdesc **)vdev; int rv; - /* * If it looks like this is just a path and no device, then * use the current device instead. @@ -61,7 +61,8 @@ } =20 /* Parse the device name off the beginning of the devspec. */ - return (efi_parsedev(dev, devspec, path)); + const int out =3D efi_parsedev(dev, devspec, path); + return out; } =20 /* @@ -87,8 +88,9 @@ int i, err; =20 /* minimum length check */ - if (strlen(devspec) < 2) + if (strlen(devspec) < 2) { return (EINVAL); + } =20 /* look for a device that matches */ for (i =3D 0; devsw[i] !=3D NULL; i++) { @@ -96,27 +98,39 @@ if (!strncmp(devspec, dv->dv_name, strlen(dv->dv_name))) break; } - if (devsw[i] =3D=3D NULL) + if (devsw[i] =3D=3D NULL) { return (ENOENT); + } + np =3D devspec + strlen(dv->dv_name); =20 - idev =3D malloc(sizeof(struct devdesc)); - if (idev =3D=3D NULL) - return (ENOMEM); + if (DEVT_ZFS =3D=3D dv->dv_type) { + idev =3D malloc(sizeof(struct zfs_devdesc)); + int out =3D zfs_parsedev((struct zfs_devdesc*)idev, np, = path); + if (0 =3D=3D out) { + *dev =3D idev; + cp =3D strchr(np + 1, ':'); + } else { + free(idev); + return out; + } + } else { + idev =3D malloc(sizeof(struct devdesc)); + if (idev =3D=3D NULL) + return (ENOMEM); =20 - idev->d_dev =3D dv; - idev->d_type =3D dv->dv_type; - idev->d_unit =3D -1; - + idev->d_dev =3D dv; + idev->d_type =3D dv->dv_type; + idev->d_unit =3D -1; + if (*np !=3D '\0' && *np !=3D ':') { + idev->d_unit =3D strtol(np, &cp, 0); + if (cp =3D=3D np) { + idev->d_unit =3D -1; + free(idev); + return (EUNIT); + } + } + } err =3D 0; - np =3D devspec + strlen(dv->dv_name); - if (*np !=3D '\0' && *np !=3D ':') { - idev->d_unit =3D strtol(np, &cp, 0); - if (cp =3D=3D np) { - idev->d_unit =3D -1; - free(idev); - return (EUNIT); - } - } if (*cp !=3D '\0' && *cp !=3D ':') { free(idev); return (EINVAL); @@ -138,10 +152,11 @@ static char buf[32]; /* XXX device length constant? */ =20 switch(dev->d_type) { + case DEVT_ZFS: + return zfs_fmtdev(dev); case DEVT_NONE: strcpy(buf, "(no device)"); break; - default: sprintf(buf, "%s%d:", dev->d_dev->dv_name, dev->d_unit); break; Index: sys/boot/efi/loader/main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/main.c (revision 281381) +++ sys/boot/efi/loader/main.c (working copy) @@ -39,6 +39,7 @@ #include =20 #include "loader_efi.h" +#include "libzfs.h" =20 extern char bootprog_name[]; extern char bootprog_rev[]; @@ -45,8 +46,9 @@ extern char bootprog_date[]; extern char bootprog_maker[]; =20 -struct devdesc currdev; /* our current device */ -struct arch_switch archsw; /* MI/MD interface boundary */ +/* our current device */ +/* MI/MD interface boundary */ +struct arch_switch archsw; =20 EFI_GUID acpi =3D ACPI_TABLE_GUID; EFI_GUID acpi20 =3D ACPI_20_TABLE_GUID; @@ -60,6 +62,70 @@ EFI_GUID memtype =3D MEMORY_TYPE_INFORMATION_TABLE_GUID; EFI_GUID debugimg =3D DEBUG_IMAGE_INFO_TABLE_GUID; =20 +static void efi_zfs_probe(void); + +static void +print_str16(const CHAR16* const str) +{ + for(int i; str[i]; i++) + { + printf("%c", str[i]); + } +} + +/* +static int +str16cmp(const CHAR16 const *a, + const char* const b) +{ + for(int i =3D 0; a[i] || b[i]; i++) + { + const CHAR16 achr =3D a[i]; + const CHAR16 bchr =3D b[i]; + if (achr < bchr) + { + return -1; + } else if (achr > bchr) + { + return 1; + } + } + return 0; +} + +// Split an arg of the form "argname=3Dargval", replacing the '=3D' with= a \0 +static CHAR16* +split_arg(CHAR16 *const str) +{ + for (int i =3D 0; str[i]; i++) + { + if ('=3D' =3D=3D str[i]) + { + str[i] =3D 0; + return str + i + 1; + } + } + return NULL; +} + +static void +handle_arg(CHAR16 *const arg) +{ + const CHAR16* const argval =3D split_arg(arg); + const CHAR16* const argname =3D arg; + + if (NULL !=3D argval) + { + printf("Unrecognized argument \""); + print_arg(argname); + printf("\n"); + } else { + printf("Unrecognized argument \""); + print_arg(argname); + printf("\n"); + } +} +*/ EFI_STATUS main(int argc, CHAR16 *argv[]) { @@ -68,7 +134,15 @@ EFI_GUID *guid; int i; =20 - /* + archsw.arch_autoload =3D efi_autoload; + archsw.arch_getdev =3D efi_getdev; + archsw.arch_copyin =3D efi_copyin; + archsw.arch_copyout =3D efi_copyout; + archsw.arch_readin =3D efi_readin; + // Note this needs to be set before ZFS init + archsw.arch_zfs_probe =3D efi_zfs_probe; + + /* * XXX Chicken-and-egg problem; we want to have console output * early, but some console attributes may depend on reading from * eg. the boot device, which we can't do yet. We can use @@ -84,13 +158,22 @@ /* * March through the device switch probing for things. */ - for (i =3D 0; devsw[i] !=3D NULL; i++) - if (devsw[i]->dv_init !=3D NULL) + for (i =3D 0; devsw[i] !=3D NULL; i++) { + if (devsw[i]->dv_init !=3D NULL) { + printf("Initializing %s\n", devsw[i]->dv_name); (devsw[i]->dv_init)(); - + } + } /* Get our loaded image protocol interface structure. */ BS->HandleProtocol(IH, &imgid, (VOID**)&img); =20 + printf("Command line arguments:"); + for(i =3D 0; i < argc; i++) { + printf(" "); + print_str16(argv[i]); + } + printf("\n"); + printf("Image base: 0x%lx\n", (u_long)img->ImageBase); printf("EFI version: %d.%02d\n", ST->Hdr.Revision >> 16, ST->Hdr.Revision & 0xffff); @@ -104,8 +187,13 @@ printf("%s, Revision %s\n", bootprog_name, bootprog_rev); printf("(%s, %s)\n", bootprog_maker, bootprog_date); =20 - efi_handle_lookup(img->DeviceHandle, &currdev.d_dev, &currdev.d_unit); - currdev.d_type =3D currdev.d_dev->dv_type; + // Handle command-line arguments + /* + for(i =3D 1; i < argc; i++) + { + handle_arg(argv[i]); + } + */ =20 /* * Disable the watchdog timer. By default the boot manager sets @@ -118,19 +206,39 @@ */ BS->SetWatchdogTimer(0, 0, 0, NULL); =20 - env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev), - efi_setcurrdev, env_nounset); - env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev), env_noset, - env_nounset); + struct devsw *dev; + int unit; + uint64_t pool_guid; + efi_handle_lookup(img->DeviceHandle, &dev, &unit, &pool_guid); + switch (dev->dv_type) { + case DEVT_ZFS: { + struct zfs_devdesc currdev; + currdev.d_dev =3D dev; + currdev.d_unit =3D unit; + currdev.d_type =3D currdev.d_dev->dv_type; + currdev.d_opendata =3D NULL; + currdev.pool_guid =3D pool_guid; + currdev.root_guid =3D 0; + env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),= + efi_setcurrdev, env_nounset); + env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev),= env_noset, + env_nounset); + } break; + default: { + struct devdesc currdev; + currdev.d_dev =3D dev; + currdev.d_unit =3D unit; + currdev.d_opendata =3D NULL; + currdev.d_type =3D currdev.d_dev->dv_type; + env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),= + efi_setcurrdev, env_nounset); + env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev),= env_noset, + env_nounset); + } break; + } =20 setenv("LINES", "24", 1); /* optional */ =20 - archsw.arch_autoload =3D efi_autoload; - archsw.arch_getdev =3D efi_getdev; - archsw.arch_copyin =3D efi_copyin; - archsw.arch_copyout =3D efi_copyout; - archsw.arch_readin =3D efi_readin; - for (i =3D 0; i < ST->NumberOfTableEntries; i++) { guid =3D &ST->ConfigurationTable[i].VendorGuid; if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) { @@ -347,7 +455,6 @@ return (CMD_OK); } =20 - COMMAND_SET(nvram, "nvram", "get or set NVRAM variables", command_nvram)= ; =20 static int @@ -399,6 +506,27 @@ return (CMD_OK); } =20 +COMMAND_SET(lszfs, "lszfs", "list child datasets of a zfs dataset", + command_lszfs); + +static int +command_lszfs(int argc, char *argv[]) +{ + int err; + + if (argc !=3D 2) { + command_errmsg =3D "wrong number of arguments"; + return (CMD_ERROR); + } + + err =3D zfs_list(argv[1]); + if (err !=3D 0) { + command_errmsg =3D strerror(err); + return (CMD_ERROR); + } + return (CMD_OK); +} + #ifdef LOADER_FDT_SUPPORT extern int command_fdt_internal(int argc, char *argv[]); =20 @@ -417,3 +545,23 @@ =20 COMMAND_SET(fdt, "fdt", "flattened device tree handling", command_fdt); #endif + +static void +efi_zfs_probe(void) +{ + EFI_BLOCK_IO *blkio; + EFI_HANDLE h; + EFI_STATUS status; + u_int unit =3D 0; + char devname[32]; + uint64_t pool_guid; + + for (int i =3D 0, h =3D efi_find_handle(&efipart_dev, 0); + h !=3D NULL; h =3D efi_find_handle(&efipart_dev, ++i)) { + snprintf(devname, sizeof devname, "%s%d:", + efipart_dev.dv_name, i); + if(0 =3D=3D zfs_probe_dev(devname, &pool_guid)) { + efi_handle_update_dev(h, &zfs_dev, unit++, pool_= guid); + } + } +} Index: sys/boot/zfs/zfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/zfs/zfs.c (revision 281381) +++ sys/boot/zfs/zfs.c (working copy) @@ -140,7 +140,7 @@ n =3D size; if (fp->f_seekp + n > sb.st_size) n =3D sb.st_size - fp->f_seekp; -=09 + rc =3D dnode_read(spa, &fp->f_dnode, fp->f_seekp, start, n); if (rc) return (rc); @@ -493,7 +493,7 @@ } } close(pa.fd); - return (0); + return (ret); } =20 /* --------------010602090203020408050102-- --5wXiKkjMGm8L5K77UST2Lh3U5c7DtNFJI 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 iQIcBAEBAgAGBQJVYPUFAAoJEEGB2s+NNG0FVHgQANAaljoGjvG6spswXKFMfwTI hAgqpD+zzSNz16BDWCczUMRgX0YWqJjKR3i9oLRvV0oWa4/oKq4iDDlqOAY1Vtjm f+4gePZl2h0Y8cOk4M7GTM3qMe3+0XfobNmENgSOnwOusBI0eX2Sbn20020tknMp 95TtQ8nAJaQ0ipY3bXD+u9Fq89LSJtc1OiH8i8CcV++QNZ61Vsr7wsGhtTu2jSDN 2lPaVOypAciHNRpJAVX5HPPIxJl53dUb/K3H/E4YFjrmOS7rEwk9Z2KAOwYIIUng 8zriGpn3G2Q1SnhW8OUw/h7+wzZGLbw7dw0GSFvgnx67UypL8K3qJEKYhWbsj0xl 8p6y+r97U+I8nXQ9DMqYSaIYT4WuSvr6S9a2cy897ENZWHAQIvpDMtlpRChGbqmf dNBA5OPmOF2aJiWHGcJ8PpAHwSzRfq9LrserICWdidqoP43+9g21ySrN0T/kAbWO go+dFX1W4s0TquraDtJLw5RIDSX3ZSJwzA1m1axecYkmGqP/bdvCZGDsNko014/t 56Z3Lah2tamUxRLKsYhPwQsp4WuXNtD7vImID0NmHIW63lt329+UmhNgCNsj1fvE ZHdeY9wbrW35GbrmiYAB62/e4kGuLVRAQcnZ2zpEPX/gS3DJrRecLCdxpTFEZL+o 2TbgrNqCGHdRO92a6aAh =Ubtv -----END PGP SIGNATURE----- --5wXiKkjMGm8L5K77UST2Lh3U5c7DtNFJI-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 23 21:55:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DD92BAC for ; Sat, 23 May 2015 21:55:20 +0000 (UTC) Received: from mail.metricspace.net (207-172-209-89.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.89]) by mx1.freebsd.org (Postfix) with ESMTP id 645401270 for ; Sat, 23 May 2015 21:55:19 +0000 (UTC) Received: from [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038] (unknown [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038]) (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 D90292F605 for ; Sat, 23 May 2015 21:55:18 +0000 (UTC) Message-ID: <5560F743.9000507@metricspace.net> Date: Sat, 23 May 2015 17:55:15 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: EFI ZFS loader successful load and boot References: <5560F4FE.4030502@metricspace.net> In-Reply-To: <5560F4FE.4030502@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W6uM5Dxm4apEwhknxxNPqcBfB4h3Pstut" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 21:55:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W6uM5Dxm4apEwhknxxNPqcBfB4h3Pstut Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One thing I forgot to mention here, my kernel is severely out of date, as around October of last year, the blank screen on resume issue showed u= p. I'll try updating to the latest and see if that helps. On 05/23/2015 05:45 PM, Eric McCorkle wrote: > There is also one other issue, which I think is the fault of my hardwar= e... >=20 > When I boot a kernel in EFI mode, it prints info about the EFI console,= > then the screen freezes. However, I can tell that the kernel and OS > finish booting, because functions like suspend-on-lid-close and the > power button work as normal after a while. However, when waking from > suspend, the screen is just blank. >=20 > This resembles an issue I've had with this particular laptop, which I'v= e > reported before on the ACPI list. Given this as well as basic common > sense, I think it's extremely unlikely that this issue arises as a > result of my modifications to loader. >=20 > If anyone out there has a ZFS-based system and can confirm or deny this= , > that would be extremely useful information. >=20 >=20 > Thanks, > Eric >=20 --W6uM5Dxm4apEwhknxxNPqcBfB4h3Pstut 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 iQIcBAEBAgAGBQJVYPdHAAoJEEGB2s+NNG0FdZYP/0vpHSrs8BfvYLmWnMoQd/np /evqyXooPUBTeM8dGpA6NjUTSWqyyovgWIv5EyO2T8K0avoEF1chjtlMF6X/5f2x 9fF5XUrQfDDl0DPF+v2AmXOvrWaYyzi4anfalHl5RuUa26gFVA7MMSEDKuAdgPlG To/fhFYbgk89abcqZW3SY6qA84GK2Lsbp9H+dkwYrrq2wSD7xm9b04Fc327Oj6Rm Z4oyZF/upwU7k0zLESAefj0ngcRpweg0SBZSrzRKSwQhn2SoHP1gd96c7yiEUOD/ rtEFOiEoxl3xauM5sGh3ss/0NNbKj5bNxEFvoZ31Jn/2/Fi2g9kjBHb2sASCszX6 9E7hn5m2qSnx6NJp2h8V9fyxcE1fJGg0B7n/XvQqGQm6wUAQW3oK3Zuxl4IeghYd m+9SHrAIHKcOaEaU83B552qK6wITjEUo5A3hWzAdXVoWk7ylYPP9ZjH3b+XTkxFi b7ut++LQXGgOyTsU+CZZTLVm5QPMnDEA2RG/n3eyK/RNMoqdik7m9TKf7RkW359Q 4O3j1BsCR+IzlC/VUpurGeRnHB2EALNZgp8KilblUhBwxJnAuGc1AoSrX6LY8zNl f/5tacZmKUe2z9kXueKbNhATOB2bW0eWB5YSFs7UMSIWIIdoIwIqe9Xw2xg+UrN2 VZn6BZzx5msjM4p+Fn6u =bXK4 -----END PGP SIGNATURE----- --W6uM5Dxm4apEwhknxxNPqcBfB4h3Pstut--