From owner-freebsd-current@freebsd.org Sun Oct 1 11:41:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B02FE14F58 for ; Sun, 1 Oct 2017 11:41:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0078.outbound.protection.outlook.com [104.47.34.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2BF582D7D; Sun, 1 Oct 2017 11:41:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB1464.CANPRD01.PROD.OUTLOOK.COM (52.132.81.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sun, 1 Oct 2017 11:41:05 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Sun, 1 Oct 2017 11:41:05 +0000 From: Rick Macklem To: Michael Butler , freebsd-current CC: "rmacklem@freebsd.org" Subject: Re: Can't NFS mount ZFS volume Thread-Topic: Can't NFS mount ZFS volume Thread-Index: AQHTOYjN+X59uTi4TECKw4yDH2UgS6LN4AWagAAWAwCAAOZ86w== Date: Sun, 1 Oct 2017 11:41:04 +0000 Message-ID: References: <4cbb6150-0fcc-5393-846f-309e19cfb0ea@protected-networks.net> , <65feb444-3265-b9bc-3d4d-d57b125513d3@protected-networks.net> In-Reply-To: <65feb444-3265-b9bc-3d4d-d57b125513d3@protected-networks.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1464; 6:7CJm+S7d0OqH3SfP951Qma8g+cNAKa2YCP1r1mXd0FsgsDmAtMVNTzCJZrll7DW6dq2XIld4zc3TUUoP8r/6MDJGZlwrTrvdD3mVEft7vzXuhd9WkeuRmeRKLg+MCFwIo2t37LtW/mvO+UvR3rUu0BviMX0ZWIFuLn9L0gVdR8rTUHAJTrgMHNQ5BcGfYsdsqPSIVKb08FotOAEEZIGoJCHT+/sVl09yy/RxG502EHXz0PSjvXFhgtdMUCqOVG2znqyvwvSkY6Z++PsTAD2NNqe+ZnnyZdBTeUKcCSrFy9OISRAsN9mCJOUQGAKqsXQ2UIM4hF+WJBV29mB2131vbQ==; 5:5JE8jEyr/BJQBI0ebjOlqS3qvaJEg7eMrZY7mk5WhU723jG4ee/X1fJgv3eehGXDe2SqPoURqHl3W+oufy9ghknopMNbzMSpTjoDQ6L4ueIm6af862TEDd/wmoUR+DOGAo1UpnqIxKVvIVnvBRp7hA==; 24:WhMNwB9PPaiCauRRfSK57zVoLVRtk3CwZtZNXqxpoE2LMuu50urVOS8Mo7EfmWbCd/JMLQiyMstb4rZpK80/DYYUMnWVX4Scgy9mokB8dT0=; 7:EeznWS0vdc5Qn6aZKfyPPdPwEwB5oJ0Fe3ykJdJSYnYulX7frD6dpxo9FYjsijhH1tT49PDmX7UpDLk4UM/z1B+josT0DtcJY+aNrF/wTpuM4y2X+dkrvwBqnxitPdGXv61TW2hvvAXxRRYys/AjemBeiX7/HXlc1rqnaYDJ7nkG7pG+R86CqmtGOH2PFg3sNG6UN9gCtSIWtONvCMZqtl6PZqYx/Pf4FJIvyCE5yEY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9c561ce2-f100-4a99-abf4-08d508c14ca2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB1464; x-ms-traffictypediagnostic: YQXPR0101MB1464: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB1464; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB1464; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(24454002)(2950100002)(25786009)(7696004)(3280700002)(33656002)(189998001)(6436002)(74316002)(14454004)(106356001)(74482002)(3660700001)(229853002)(8936002)(2900100001)(101416001)(478600001)(6506006)(50986999)(76176999)(81166006)(305945005)(86362001)(81156014)(97736004)(4326008)(53936002)(6246003)(8676002)(105586002)(54356999)(2906002)(102836003)(5660300001)(55016002)(786003)(5250100002)(316002)(110136005)(68736007)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB1464; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 11:41:04.8670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 11:41:13 -0000 Michael Butler wrote: > I have no idea why but using .. > > sudo /sbin/mount vm01:/usr/local/exports/ /mnt This is weird. I would have thought they would both result in the same behaviour. > .. instead of .. > > sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt Did this work with the older system?. I'll admit I always go "su" and then do the mount command as # mount -t nfs vm01:/usr/local/exports /mnt" Please let us know if this doesn't work. (If you try this and it doesn't work, then something is definitely broken.) I don't even have sudo. (It's a port and my guess would be some issue related to how either it or "mount" parses things.) rick = From owner-freebsd-current@freebsd.org Sun Oct 1 13:10:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4A8FE2455D for ; Sun, 1 Oct 2017 13:10:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEC51E0 for ; Sun, 1 Oct 2017 13:10:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8C0F3E2455C; Sun, 1 Oct 2017 13:10:15 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BA3FE2455B for ; Sun, 1 Oct 2017 13:10:15 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5243B1DF for ; Sun, 1 Oct 2017 13:10:14 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dydGO-00026u-Ti for current@freebsd.org; Sun, 01 Oct 2017 14:22:29 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dydGO-0005zG-SW for current@freebsd.org; Sun, 01 Oct 2017 14:22:28 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Sun, 01 Oct 2017 12:22:28 GMT From: "Jeffrey Bouquet" To: "current" Subject: Newbie q [repost] Date: Sun, 01 Oct 2017 05:22:28 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 13:10:15 -0000 I've a uname-a : STABLE-11 that svn's to 12-HEAD and will not buildworld d= espite 'make cleanworld ' and '/bin/rm -rf /usr/obj/usr' both... and src.conf an= d=20 make.conf removed from /etc.=20 ........................... libmap.conf problem? unpack base.txz etc how? pkg of base ready somewhat and a how to ? wait out v12 and v13 is HEAD ? remove disk, new install and copy over .rc [etc] from old system? .............. No urgency but has been ongoing for over a year maybe even over two years. .............. J Bouquet [ bsd 2004 january, full desktop with initial 2004 files stil= l throughout filesystem ]=20 [ the above system not the one in the line above but t= his email can answer both=20 as I cannot easily risk the latter loss of f(), nvi= dia drivers etc. ]=20= From owner-freebsd-current@freebsd.org Sun Oct 1 14:34:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FEA5E26013 for ; Sun, 1 Oct 2017 14:34:18 +0000 (UTC) (envelope-from danny@mail.hebrew.edu) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 07C6229A4 for ; Sun, 1 Oct 2017 14:34:17 +0000 (UTC) (envelope-from danny@mail.hebrew.edu) Received: by mail-wm0-x22f.google.com with SMTP id u138so6338074wmu.5 for ; Sun, 01 Oct 2017 07:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-hebrew-edu.20150623.gappssmtp.com; s=20150623; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=06qTNLxsfs937XVuGPtHlUEVouWDZ57ovcwhSm9waX8=; b=FiQcAMBAAByLixbS/rA4PFVsr9nj3sk4sQ6mQr4eknhY33kUaFJO+hEG911r+XTedi aQvOmY52ahAbJNIenWOOaTf4fo5Xs2lK/KnVxS/BrZ7tuvPGu0UatbORM/khoJPdPM1K dSGKmmi0lQPSwNGRM6RB4VO/4bXXwNM611jMzTD7zeK5a6CCvAyqf5Dr2w6lTfUYJOk3 nEaJ5TGQ3JNhGSpPavh2APnnuE9/ErzLJDMpDjSsLzUPwFj/iwncYaC6M7uZfTApyMlE lhA8XfKhU2T7ceqmR2hnJ4tGWrLQMRVskOOwprwaxrwrMpm55v0W/k20dpAn762Bh7ZK vz3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=06qTNLxsfs937XVuGPtHlUEVouWDZ57ovcwhSm9waX8=; b=DXubYJt+PObIkELIlGtyslnMvmHQWPpH5lfizd0m1MEzlm3XHaCLHnPUSsan9glCrv SZp9tzfIbtrYAPxWQnD+AktSyQnB8z+9nRNpkL6UI5kikuw0BZzocUGwSHdkPP9AbloM ZYiopvDMuUv2lwPUyVC8sYvbB3isxFU5yikMpyuGSADJyKGfc7Df7sYi23QbUjY65ygN KIP3XPvhsUcPhfsQiGyFunolOCiAC859GywZ79Zs+gjD7EwazXg/UsXI7aklHlh5aoow ZS9GgEhnmWFL4X6KkjrhXWjYG7NifjRvMk60hS+tTZSmPSvVbYqX7CXtO3ahJN5iIybg odbg== X-Gm-Message-State: AMCzsaVIjJAr2T/ObyEVEIbG/wpv9o5jxedER5F7eBvHtvOtsysXLs0/ 5LvSK31kfABir2JVyvuumEu/GA== X-Google-Smtp-Source: AOwi7QB6tpW6E14cbLetzW+URyIrTmW039bhokM7J1vEzvNEc1nHImMSB8U7X0lnCdV0RRMnxgpIxg== X-Received: by 10.28.130.130 with SMTP id e124mr7599629wmd.75.1506868455662; Sun, 01 Oct 2017 07:34:15 -0700 (PDT) Received: from [192.168.1.16] ([46.121.232.8]) by smtp.gmail.com with ESMTPSA id i7sm5647640wmc.18.2017.10.01.07.34.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 07:34:14 -0700 (PDT) Sender: Danny Braniss Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Can't NFS mount ZFS volume From: Daniel Braniss In-Reply-To: Date: Sun, 1 Oct 2017 17:34:27 +0300 Cc: Michael Butler , freebsd-current , "rmacklem@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: References: <4cbb6150-0fcc-5393-846f-309e19cfb0ea@protected-networks.net> <65feb444-3265-b9bc-3d4d-d57b125513d3@protected-networks.net> To: Rick Macklem X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 14:34:18 -0000 > On 1 Oct 2017, at 14:41, Rick Macklem wrote: > > Michael Butler wrote: >> I have no idea why but using .. >> >> sudo /sbin/mount vm01:/usr/local/exports/ /mnt > This is weird. I would have thought they would both result in the same > behaviour. >> .. instead of .. >> >> sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt > Did this work with the older system?. > I'll admit I always go "su" and then do the mount command as > # mount -t nfs vm01:/usr/local/exports /mnt" > Please let us know if this doesn't work. > (If you try this and it doesn't work, then something is definitely broken.) > > I don't even have sudo. (It's a port and my guess would be some issue > related to how either it or "mount" parses things.) > the not working is : mount host:/path some-local-path which should default to -t nfs, and at least in 11.1 it works danny > rick > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Oct 1 15:00:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B728E26B9E for ; Sun, 1 Oct 2017 15:00:38 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CB3F38EB for ; Sun, 1 Oct 2017 15:00:37 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [IPv6:2001:8b0:151:1:8d79:2312:1fde:a9c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 4585330C5 for ; Sun, 1 Oct 2017 15:00:28 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Subject: Re: Newbie q [repost] To: freebsd-current@freebsd.org References: From: Matthew Seaman Message-ID: <63421c25-68bd-e733-2e43-96c47a14b4b8@FreeBSD.org> Date: Sun, 1 Oct 2017 16:00:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nNEGaWRgHE9JjLKn5Xs8Wswqrmg24lG6H" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 15:00:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nNEGaWRgHE9JjLKn5Xs8Wswqrmg24lG6H Content-Type: multipart/mixed; boundary="n5HjW4hV36oWxOK2NSDoB0pD790IBSnqH"; protected-headers="v1" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <63421c25-68bd-e733-2e43-96c47a14b4b8@FreeBSD.org> Subject: Re: Newbie q [repost] References: In-Reply-To: --n5HjW4hV36oWxOK2NSDoB0pD790IBSnqH Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 01/10/2017 13:22, Jeffrey Bouquet wrote: > I've a uname-a : STABLE-11 that svn's to 12-HEAD and will not buildwor= ld despite > 'make cleanworld ' and '/bin/rm -rf /usr/obj/usr' both... and src.con= f and=20 > make.conf removed from /etc.=20 > ........................... > libmap.conf problem? > unpack base.txz etc how? > pkg of base ready somewhat and a how to ? > wait out v12 and v13 is HEAD ? > remove disk, new install and copy over .rc [etc] from old system? > .............. > No urgency but has been ongoing for over a year maybe even over two yea= rs. > .............. So, is your question "how can I fix the build problems" or "how can I upgrade to 12-CURRENT _without_ having to build world"? If the former, then you'll have to give us at least something to go on. Saying "it doesn't work" may be completely factual, but it doesn't help at all in working out why not. If the latter then there are current snapshots available from eg. http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/ or as installer images from http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/ I'd advise going for a new 12.0 install and porting over any configuration files etc. -- ideally leaving your existing 11-STABLE system still available so you can boot back into that in case of difficulties. Cheers, Matthew --n5HjW4hV36oWxOK2NSDoB0pD790IBSnqH-- --nNEGaWRgHE9JjLKn5Xs8Wswqrmg24lG6H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJZ0QMMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATbVAQAJmLiBKeyNGbcwf5j34MUrCS oM7EWATlJF/jfMgOjGZ2pUtOsQqTHme68O+UGRvV7478bnCvcHt37TPGI3a3axns tTjv+SfYxRc2n/7Bsq0d72oYj6QqgqzGdEqJafb2WKRtkEiAUr1u3m4/5ZBw2HN0 kgKqQxT68pO8tLo4/uwZhWJK3MzJRF3keG5mi2EEyUWzusmX/dUjsKB/Q3ucDigU lSu0chomqoxWC2puSVbCDrxdwqNUi0C+1r5V+TRbghpjJI7oQKjGMJBIvKGXv8qG mGRlEuYPS0Pw3hybzCeN6eaNV3C1EXkxvr069C2NBFGGmIjudDC4K5WEh0JM2g9p iIv/iv+1FJ3LRSEEdSxnPJdwQnmmQfusW4Fh/jNfgRWW5/SX1FqUX8OcwdjrTjuv flb+nrYp7Z91bx52zNgl0Gxsk8UcdrqwuD5shCO0ArN3OrLm0LqR/fPbKYAbdyZN h00I/XZPro6cESQHWlakjKlbC7ulp1iCWHt/MhpJ4TrQawOoyXfDiOwUtuuNqZg4 ciYClfW/CElEgIs93hv/UhEgdvbffNPqZTikNKAxmAgcP30taNhD5EJjjPCNmnVw pnkQTxpIkv+Ydd58vBZQ0Y2s+BNjhuLXZdhQbkbfX+fvrdMyV2e5pesAK2TBnuyN nLsrLRg87pi7Hdz6f7pm =XrMO -----END PGP SIGNATURE----- --nNEGaWRgHE9JjLKn5Xs8Wswqrmg24lG6H-- From owner-freebsd-current@freebsd.org Sun Oct 1 16:41:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3ECEE28DB5 for ; Sun, 1 Oct 2017 16:41:05 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from n6.nabble.com (n6.nabble.com [162.255.23.37]) by mx1.freebsd.org (Postfix) with ESMTP id D437C65FFA for ; Sun, 1 Oct 2017 16:41:04 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from n6.nabble.com (localhost [127.0.0.1]) by n6.nabble.com (Postfix) with ESMTP id 0034B2009F10 for ; Sun, 1 Oct 2017 09:40:58 -0700 (MST) Date: Sun, 1 Oct 2017 09:40:57 -0700 (MST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1506876057998-0.post@n6.nabble.com> In-Reply-To: References: Subject: Re: Newbie q [repost] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 16:41:06 -0000 I can't help noticing your signature, so clean installation is always a good start. -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-current-f3875308.html From owner-freebsd-current@freebsd.org Sun Oct 1 20:40:27 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA3AEE2E14E for ; Sun, 1 Oct 2017 20:40:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0069.outbound.protection.outlook.com [104.47.34.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 662316E29A; Sun, 1 Oct 2017 20:40:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB1287.CANPRD01.PROD.OUTLOOK.COM (52.132.80.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sun, 1 Oct 2017 20:40:24 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Sun, 1 Oct 2017 20:40:24 +0000 From: Rick Macklem To: Daniel Braniss CC: Michael Butler , freebsd-current , "rmacklem@freebsd.org" Subject: Re: Can't NFS mount ZFS volume Thread-Topic: Can't NFS mount ZFS volume Thread-Index: AQHTOYjN+X59uTi4TECKw4yDH2UgS6LN4AWagAAWAwCAAOZ864AANS6AgABlOsQ= Date: Sun, 1 Oct 2017 20:40:24 +0000 Message-ID: References: <4cbb6150-0fcc-5393-846f-309e19cfb0ea@protected-networks.net> <65feb444-3265-b9bc-3d4d-d57b125513d3@protected-networks.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1287; 6:cX15MuWMsXh6M2oBDcYTDnFuCHwMi+n/NNYrgW/p2XmIXfofteaj86t0NgOkW6+dppK8Jr4BqY9QplHv1ITuVzRpSVe/a9aCwCzR6PNkkPBG4BI+DJRd96xphEaMP5IVEeFozSimerOG5+VvzXhbjHWVwbbNwW/p1uoEDEYhZ9vKdLr6wWdoynhGIMnzNx00+t2Ow4cJEmI9FwxbCAhiAkMcknn0kKQ++GmEQj5gq3lXApdfrUZVY4On37kudWjWXhiwwcxS0SxknRaH3mZADM9PiPIpQhxwU1DvEFhV9FqIt5AmYNgA6q9JkBBCoXlnCgxg8HM+0eg0XOJXlgZDkA==; 5:79W09O+J9rSHhDyuGHvOwkAAbl2nrCqWwdvdiZjVYt+OG8yTFff/RADbL6tlDlxy0wJ9Bz/gnAsYWhVrLjM3+bu4HYpNfEVAijzbumbyHbuiGdB+EiB/m2rTxlf6QIEW2RQbh3kSUOC7hj1T9EiEhKM5m1aPhYj3SNy0QqMfDGA=; 24:Pt6Nlae+XD3kZ75AYKachZ2BNiDKEWAYdGxSt1pmpc8r/L/PxqfAne/M3MyPDnL2TpDgpR3N+ZNzEBNLDwqwZ6jtGrnvpegHHr+gocnbgoQ=; 7:klkLAO25b/ptctJ3N3XfHzF0s3Pj0v8lHKC9NA8kamrdslsF8lGrJ3X3dFRzSQ0Kml8d2IAnSDI9GMua4USW92u+oqlYcblX9J+JOc/0KekuNiNsjIIOrV8yyO4d2fIBzR7M/dYWTeGOsjdzrrtXqoivdg9fzfpRCshG3ArdHgCEIDb4rGKOqQslYrpRErbsG/QO18rfFuL2PfXg36vgAiapc58qvqi5VZ4sjpG1tME= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d62274f8-2c1e-452e-7ce5-08d5090ca49b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB1287; x-ms-traffictypediagnostic: YQXPR0101MB1287: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB1287; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB1287; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(346002)(376002)(24454002)(199003)(189002)(102836003)(5660300001)(9686003)(54356999)(316002)(3660700001)(2900100001)(786003)(2950100002)(54906003)(101416001)(189998001)(93886005)(97736004)(6246003)(5250100002)(106356001)(33656002)(7696004)(6916009)(8676002)(105586002)(14454004)(8936002)(53936002)(4326008)(76176999)(229853002)(74482002)(55016002)(6506006)(50986999)(478600001)(2906002)(25786009)(81166006)(305945005)(86362001)(6436002)(74316002)(3280700002)(81156014)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB1287; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 20:40:24.7922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1287 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 20:40:27 -0000 Danny Braniss wrote: > Michael Butler wrote: >> I have no idea why but using .. >> >> sudo /sbin/mount vm01:/usr/local/exports/ /mnt >> .. instead of .. >> >> sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt > > the not working is : > mount host:/path some-local-path > > which should default to -t nfs, and at least in 11.1 it works > danny My understanding of his post was the above worked and mount -t nfs host:/path some-local-path did not work, when done via sudo. (Both seem to be fine when not using "sudo".) rick From owner-freebsd-current@freebsd.org Sun Oct 1 22:12:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C3EBE2FCB8 for ; Sun, 1 Oct 2017 22:12:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0041.outbound.protection.outlook.com [104.47.33.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E72E70FB5 for ; Sun, 1 Oct 2017 22:12:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB1479.CANPRD01.PROD.OUTLOOK.COM (52.132.81.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sun, 1 Oct 2017 22:12:07 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Sun, 1 Oct 2017 22:12:07 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: panic in AcpiOsGetTimer during boot. Thread-Topic: panic in AcpiOsGetTimer during boot. Thread-Index: AQHTOwGAIy8rz5AXN0ORsi5i7QtdWQ== Date: Sun, 1 Oct 2017 22:12:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1479; 6:GPa1kFrCK4FAAdSTn7jho6m564azDbWIzoU82gGke7yOT4/fwxAD+yHT9dR8/RC87Be+T4DMWZcU5USFCeJTpRsUPDO3KJbdgAmRa8bWHDeE2CchUSDCs/CySu90qZyg/uAfJzzH/IhslaYcKmMj9W9JQLV55UEW+MNgBBayURwDtd4d3ybRUhjz2nLBFw5ZyZ51WXCS6GyuKDoZtDqmJ/E5jXgeUjv96sWgi0noskyUe7db9NSWRdhdVkvUsSBYmx3+i86KDub5As63GuzuOgS6UkYfdm6k+zVhxQP66lM7tHVtga7g9P4yY9zaX9rq7DawkPRc8zxwmd/z2KH9og==; 5:ZXfQNK45XRZe10CebI7zslMZ7V0rju9reLWbGAkMz0onUrPn6cSMOofVEf62kzR5eVeRYxsu4m79FuAlIArV9PC0ECiNlqlOPKlEY3ucrHi1CuxBhX54RVY1kJ56AvgD6o44msge6l/6QmLwkvKmzA==; 24:Yr+aoCKsi+HnPVmBLm6niMLtXbhw5H2lsmRKJ+/o213g1WOOA4nXWDEe9CPf3vmZz/zHnbjuWgGJTkM72o30qol8tqXyiAgchboaps7BdH8=; 7:fPGGNAgztmdKGQEnHnQmdCablxRf1ORe+qSbywS3/5y9CGXT9Lvre+9M6zcCj/uNDbxWMwxnqvogmNY8AUURECBpSOoCSYG7Q9vzPEY3/jmAB9nTbi0l+x9wHxB4DoQ1NulpoUlZt5qsZEGpPHUAwnnE3k1CzCH/niyL5bhgd2qoaBonxPUoCM3YW032mxx/pt4Jnt6Oe5sS7i+9JIUP0lpAlJdyFFRvd1rka4wzRfc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b9aa40ee-e753-4bc2-4930-08d509197476 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB1479; x-ms-traffictypediagnostic: YQXPR0101MB1479: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB1479; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB1479; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6029001)(6009001)(346002)(376002)(189002)(199003)(13734003)(6436002)(33656002)(316002)(5250100002)(81166006)(53936002)(81156014)(68736007)(2351001)(105586002)(7696004)(101416001)(5890100001)(74316002)(5660300001)(25786009)(86362001)(478600001)(2501003)(786003)(106356001)(2900100001)(50986999)(6506006)(2906002)(14454004)(54356999)(3660700001)(114624004)(74482002)(3280700002)(55016002)(6916009)(305945005)(8936002)(97736004)(189998001)(9686003)(8676002)(5640700003)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB1479; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 22:12:07.4284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1479 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 22:12:10 -0000 Hi, I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day o= ld) kernel. When I delete the KASSERT(), the kernel boots and seems to work ok. (This is the AcpiOsGetTimer() in sys/dev/acpica/Osd/OsdSchedule.c. There al= so seems to be one of these functions under contrib.) Here is my dmesg after boot, if it helps indicate why this is called when "= cold" is still set. (I've marked where the dmesg ends when it Panics if the KASSE= RT() is enabled.) dmesg after booting: Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #1: Sun Oct 1 09:48:42 EDT 2017 root@nfsv4-newerlap.rick.home:/sub1/sys.headsep30/amd64/compile/GENERIC= amd64 FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (2294.84-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306a9 Family=3D0x6 Model=3D0x3a Steppi= ng=3D9 Features=3D0xbfebfbff Features2=3D0x7fbae3bf AMD Features=3D0x28100800 AMD Features2=3D0x1 Structured Extended Features=3D0x281 XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16518905856 (15753 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads random: unblocking device. arc4random: no preloaded entropy cache ioapic0 irqs 0-23 on motherboard SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! **** dmesg ends here when in KASSERT() panics. SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1147419696 Hz quality 1000 random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0xffffffff80f779d0, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xf6000000-0xf6fff= fff,0xf0000000-0xf3ffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci= 1 vgapci0: Boot video device hdac0: mem 0xf7080000-0xf7083fff irq 17 at de= vice 0.1 on pci1 xhci0: mem 0xf7300000-0xf730ffff i= rq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0: waiting for BIOS to give up control xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7318000-0xf73183ff i= rq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus1: 480Mbps High Speed USB v2.0 hdac1: mem 0xf7310000-0xf7313fff irq 2= 2 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 iwn0: mem 0xf7200000-0xf7201fff irq 17 at = device 0.0 on pci3 arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 alc0: port 0xd000-0xd07f mem 0x= f7100000-0xf713ffff irq 19 at device 0.0 on pci4 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FD= X, 1000baseT-FDX-master, auto, auto-flow alc0: Using defaults for TSO: 65518/35/2048 alc0: Ethernet address: 10:bf:48:23:08:56 ehci1: mem 0xf7317000-0xf73173ff i= rq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 usbus2: 480Mbps High Speed USB v2.0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060= -0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xf7316000-0xf73167ff= irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 est0: on cpu0= From owner-freebsd-current@freebsd.org Mon Oct 2 02:21:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1920AE33E98 for ; Mon, 2 Oct 2017 02:21:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) (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 CC70176DF6 for ; Mon, 2 Oct 2017 02:21:34 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f176.google.com with SMTP id u205so2836640ywa.5 for ; Sun, 01 Oct 2017 19:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Fe/T2dZdIsiBo+iSfWpW5vRken5fLEbfiQvrIpi6ikc=; b=rVRevncNApzqG94Lqf71LpCiE8m0M6LHH70T+kQvSqLZWL6ApqmwtAgAT3n67vT5YA Zg5bQsMnHwXDDOFYnBDhLfFDEBspmP1CcCaphy62BAIi1cTlLuc0Vp5XR9zkURAIlmru 2nUWF61d62e1OgU2zL/XT7Sji5J/RDgQaBt/mAfmfJYnasuM/plQMlG4dJ3OSf3KfLAY Pl8oVgGZhtrw6PvqmHaRspWjrIlsLrai+VFEQUwW74gC8EIuDRCBNYSmI2+5dsskvysi wUuybA/0nFOjnLFAevNmKItzCmoIa5TvIftlWYCwgB/+iCgGlIN1Jn4TPiRIvdr2aVLP 70Yg== X-Gm-Message-State: AHPjjUh3dhWUsNmDWh/DL1kvOSh3D0ZDwx/Z4u7TCTGblr8wHcUrZvd3 DJ8fxHat177wq+f9MAsfcrEFNyJK X-Received: by 10.129.85.88 with SMTP id j85mr11481163ywb.214.1506910887800; Sun, 01 Oct 2017 19:21:27 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id g84sm3975565ywg.100.2017.10.01.19.21.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 19:21:27 -0700 (PDT) Received: by mail-io0-f175.google.com with SMTP id v36so3694602ioi.1 for ; Sun, 01 Oct 2017 19:21:26 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCNXx9cYD+bh40TbEZWvAT1nZzr8fgpsD5Bln1EK4rCnQoSKYrmvhtvoYWKJIIdjRTUWAddOY02QWuSBYiyuyk= X-Received: by 10.107.11.102 with SMTP id v99mr20687814ioi.260.1506910886280; Sun, 01 Oct 2017 19:21:26 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.137.79 with HTTP; Sun, 1 Oct 2017 19:21:25 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Sun, 1 Oct 2017 19:21:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: panic in AcpiOsGetTimer during boot. To: Rick Macklem Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 02:21:35 -0000 Hey Rick, Are you running into the same issue reported on this svn-src thread? https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151775.html I believe jkim has reverted the change in a subsequent revision (r324136). Best, Conrad On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem wrote: > Hi, > > I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day old) > kernel. When I delete the KASSERT(), the kernel boots and seems to work ok. > (This is the AcpiOsGetTimer() in sys/dev/acpica/Osd/OsdSchedule.c. There also > seems to be one of these functions under contrib.) > > Here is my dmesg after boot, if it helps indicate why this is called when "cold" > is still set. (I've marked where the dmesg ends when it Panics if the KASSERT() > is enabled.) > > dmesg after booting: > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #1: Sun Oct 1 09:48:42 EDT 2017 > root@nfsv4-newerlap.rick.home:/sub1/sys.headsep30/amd64/compile/GENERIC amd64 > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (2294.84-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > Features=0xbfebfbff > Features2=0x7fbae3bf > AMD Features=0x28100800 > AMD Features2=0x1 > Structured Extended Features=0x281 > XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > avail memory = 16518905856 (15753 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: <_ASUS_ Notebook> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads > random: unblocking device. > arc4random: no preloaded entropy cache > ioapic0 irqs 0-23 on motherboard > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #4 Launched! > **** dmesg ends here when in KASSERT() panics. > SMP: AP CPU #5 Launched! > SMP: AP CPU #2 Launched! > Timecounter "TSC-low" frequency 1147419696 Hz quality 1000 > random: entropy device external interface > netmap: loaded module > [ath_hal] loaded > module_register_init: MOD_LOAD (vesa, 0xffffffff80f779d0, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > kbd1 at kbdmux0 > nexus0 > vtvga0: on motherboard > cryptosoft0: on motherboard > acpi0: <_ASUS_ Notebook> on motherboard > acpi_ec0: port 0x62,0x66 on acpi0 > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: registered as a time-of-day clock, resolution 1.000000s > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xe000-0xe07f mem 0xf6000000-0xf6ffffff,0xf0000000-0xf3ffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 > vgapci0: Boot video device > hdac0: mem 0xf7080000-0xf7083fff irq 17 at device 0.1 on pci1 > xhci0: mem 0xf7300000-0xf730ffff irq 16 at device 20.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0: waiting for BIOS to give up control > xhci0: Port routing mask set to 0xffffffff > usbus0 on xhci0 > usbus0: 5.0Gbps Super Speed USB v3.0 > pci0: at device 22.0 (no driver attached) > ehci0: mem 0xf7318000-0xf73183ff irq 16 at device 26.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > usbus1: 480Mbps High Speed USB v2.0 > hdac1: mem 0xf7310000-0xf7313fff irq 22 at device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > iwn0: mem 0xf7200000-0xf7201fff irq 17 at device 0.0 on pci3 > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > pcib4: irq 19 at device 28.3 on pci0 > pci4: on pcib4 > alc0: port 0xd000-0xd07f mem 0xf7100000-0xf713ffff irq 19 at device 0.0 on pci4 > alc0: 11776 Tx FIFO, 12032 Rx FIFO > alc0: Using 1 MSI message(s). > miibus0: on alc0 > atphy0: PHY 0 on miibus0 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > alc0: Using defaults for TSO: 65518/35/2048 > alc0: Ethernet address: 10:bf:48:23:08:56 > ehci1: mem 0xf7317000-0xf73173ff irq 23 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > usbus2: 480Mbps High Speed USB v2.0 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xf7316000-0xf73167ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich2: at channel 2 on ahci0 > ahciem0: on ahci0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > est0: on cpu0 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Oct 2 04:35:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81A29E35F4D for ; Mon, 2 Oct 2017 04:35:28 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 1EC287E645 for ; Mon, 2 Oct 2017 04:35:28 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id a18so4647110lfl.13 for ; Sun, 01 Oct 2017 21:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=bn8Kc+WH4b86Rn3Byfd6luyrpuvBiozFlIl2B0C93OM=; b=QIAj+VM+BDmEHNM+sAj/aPU8JACbEPoBl3Bx8XaDJgvDZI0vmwO+ADqXmEToCiUmNI f6NAWK5NZBl3aX9I+EAIAVU1B5v+dzRTGNDy1kokQqCHSjMPLIUPr9yvuOtySJufNS3q 4NGs+vJWHDu5QyBySqQIp6RtRMcM8Nc7uc/bFqC6p1I20+sPfdJxv3hLnwhSVLqKUxbb F9bIKpUP2nox2zEkQjpNczwIOcsiXXkJEEspovNSfqIZcTQii8ac4fwUtTOIxM2fe2mt oOTbeDSqUK1PHAb92LGn5szr/nbFZucLIbvuLnkQ+ctuCDezVdT0ZtJ/73lyqG4T2E3B bg9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=bn8Kc+WH4b86Rn3Byfd6luyrpuvBiozFlIl2B0C93OM=; b=t3EYvFHYTMDL4LsR8C911WEFraQmg2KfQuxR68uXWQKxFncFiv54PnF4bEItKHXDxf DXSGDiuMloJYyXfO9KPPZ/bRMsesYGgnktVPyVCWhPSlXH7sdiNiEqhZuq5afLU+DmoA 1/2wKJhfUHWyeEdm3vJaY0w8GTwWtD8tYDq06H4x49QBSORvhxR86cGXbKUmDwzJCEVs A3oAvrkePL4DI/jVY0VBSTNpVAswU414XRQZUrNEMubbsS4QzoKY+54MWfQn8slAVpX2 VgO+5erO4iGFtLLUaHaVeHD69m+vH4seT0k+U2Whfexbvu/g6uC6ezrpICj4GIW/zrxp L9xA== X-Gm-Message-State: AHPjjUgw9QD/DI1lSxSu8GAqkViww3JyJ7jPTRX1CX+1FncbgZuS0eZX W0qwqiAJrLL4Y2zLEF/+ixdBzg== X-Google-Smtp-Source: AOwi7QDLQyCN6cne4ID4mzFovzZ2wNQ/qtrTWNKaZoP8vqUvgeVIsE6VDUwOXhqcnemm/ksPVPEjlw== X-Received: by 10.46.91.144 with SMTP id m16mr6603692lje.95.1506918926168; Sun, 01 Oct 2017 21:35:26 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id f34sm2157497lji.49.2017.10.01.21.35.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 21:35:24 -0700 (PDT) To: "freebsd-current@freebsd.org" From: "Alex V. Petrov" Subject: Build error: 'isa/rtc.h' file not found Message-ID: Date: Mon, 2 Oct 2017 11:35:22 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 04:35:28 -0000 revision 324186 In file included from /usr/obj/usr/src/tmp/usr/include/sys/efi.h:33: /usr/obj/usr/src/tmp/usr/include/machine/efi.h:35:10: fatal error: 'isa/rtc.h' file not found -- ----- Alex. From owner-freebsd-current@freebsd.org Mon Oct 2 07:44:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BFF9E38DB0 for ; Mon, 2 Oct 2017 07:44:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6D0C83094 for ; Mon, 2 Oct 2017 07:44:45 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.53.138.91]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVJze-1dpTSX0DPy-00YgYS; Mon, 02 Oct 2017 09:44:43 +0200 Date: Mon, 2 Oct 2017 09:44:36 +0200 From: "O. Hartmann" To: "Alex V. Petrov" Cc: "freebsd-current@freebsd.org" Subject: Re: Build error: 'isa/rtc.h' file not found Message-ID: <20171002094436.0fc6ab5b@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/JRh=+wnuinE_IsoEoiPjWiw"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:XM0VTM3gYgE120IrC00K5jphGm7yvS5sx0ns8ihmY+trNFYlwly 9DLvxev7G18e8XBdqwj6CJHvEuQjt0C46QlEX24kYNaYkkwQSb40jdZBEe90N6QBMGBqO2y 6rhALFgiPgjZO5Kld47dr5AuDyl6Zcd9J6HK6yong+WMkhFQD4cFzjPncPMu6kcNMDgx5Xc 2hjDYk5sHS6i38ZeaK/Kg== X-UI-Out-Filterresults: notjunk:1;V01:K0:D7/2f3NDUks=:BTgt8ZNKT38bMCSTU9qDh8 Qv2vrRQIwOJtvPBBxpLK4IzozisrcPak8eKcK49Db4fNErEgDyIZRCkQhY2878jbP9rTiKa0i hJEJLrdG9adIlZreV5WW4qjjEo/Cy0rL5b2RpnC0lLvkbWJ3PphZEbtsF/AoBjJF4aKHNaeve 5Su/ukxDLvDBCrPfpfdPId1AIhPGaF9A1vpPLgdl1RMlucGB4N7OFkJzFY+UMUmoIXtb1IK+V sRcnaS/EETQHVArt0SUR3AIajvP6cQMxpkcuLBvKK/Z3/GR1x9pIXivqnsMPaaEjDLC5H882l yevNz78bV/EkC1iv5TgLiN6S7QeFOdeEKcCNwNRMMspOxLwhpO3Odz0rAT9RGqEHZJgVMZkmL 4zX2HlhTFD/G8s026AJYQdQuLkQ9dgZ+ESeezzfXsEbXRbjmPD/fMnheJ4P+J3ym0+IDYySmR oiCNIXQGbJOIKxq4uch0oH/uNDXCdaF0c6Tei1V02owHGbFBBPICntb9NqzML/joFxExjfJ8n u3mVUkUFt9h8085a3byBOt+toM9EmkkhEPRnGECTXvrqqI2K60+4A9w/q1iZfQEI9G/ddeqU5 E/PGs6lRyLUfClz5M+q0M88Ps/DdGfyMCY35cUnyAZuiWdWEbqeELgN0pru7jEFOoGQ4Dr3UI EPxxlXMJVTiFNn3hq+TD/RlP5QiCnZ3mZ8vM+jVI3FJz/wGd6E5S9degX886epTc2p0tUax7S aFeWWxBc5iDTSNM4n4WARjQi/lFatG1s3JWcxz57+zhyXW76+FacMs7zluFzndo4xlVKjG+B4 icepQsar5HBcinUDvKzlhcR0vEJdw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 07:44:47 -0000 --Sig_/JRh=+wnuinE_IsoEoiPjWiw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 2 Oct 2017 11:35:22 +0700 "Alex V. Petrov" schrieb: > revision 324186 > In file included from /usr/obj/usr/src/tmp/usr/include/sys/efi.h:33: > /usr/obj/usr/src/tmp/usr/include/machine/efi.h:35:10: fatal error: > 'isa/rtc.h' file not found Me, too here. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/JRh=+wnuinE_IsoEoiPjWiw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdHuZAAKCRDS528fyFhY lN88Af4tk2Aj7GxlhUUAcfYlcij74HViHFxeAZXKwejTrQOJNjzpjVlJHQUi1Io/ TKbYSilaYMizvP+ZjYs6LrAr/OOtAgCeZu204xqQAjdxJ+e3wsvnF61DZQhsf7Ee vw3Or+AWrT7zHtOQ3clBdOb2vivP0x9HLy2wx5QA3lsWOvsHzC3M =lki/ -----END PGP SIGNATURE----- --Sig_/JRh=+wnuinE_IsoEoiPjWiw-- From owner-freebsd-current@freebsd.org Mon Oct 2 08:01:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C41C8E3929D for ; Mon, 2 Oct 2017 08:01:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FFE1836BE; Mon, 2 Oct 2017 08:01:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v9281Ph9083508 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Oct 2017 11:01:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9281Ph9083508 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9281PjF083507; Mon, 2 Oct 2017 11:01:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Oct 2017 11:01:25 +0300 From: Konstantin Belousov To: "O. Hartmann" Cc: "Alex V. Petrov" , andrew@FreeBSD.org, lwhsu@FreeBSD.org, "freebsd-current@freebsd.org" Subject: Re: Build error: 'isa/rtc.h' file not found Message-ID: <20171002080125.GR95911@kib.kiev.ua> References: <20171002094436.0fc6ab5b@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171002094436.0fc6ab5b@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 08:01:30 -0000 On Mon, Oct 02, 2017 at 09:44:36AM +0200, O. Hartmann wrote: > Am Mon, 2 Oct 2017 11:35:22 +0700 > "Alex V. Petrov" schrieb: > > > revision 324186 > > In file included from /usr/obj/usr/src/tmp/usr/include/sys/efi.h:33: > > /usr/obj/usr/src/tmp/usr/include/machine/efi.h:35:10: fatal error: > > 'isa/rtc.h' file not found > > Me, too here. > I am only starting the build, but I believe that the following patch should give the fix. diff --git a/sys/amd64/include/efi.h b/sys/amd64/include/efi.h index 75d39592e28..eaea8d03276 100644 --- a/sys/amd64/include/efi.h +++ b/sys/amd64/include/efi.h @@ -32,8 +32,6 @@ #ifndef __AMD64_INCLUDE_EFI_H_ #define __AMD64_INCLUDE_EFI_H_ -#include - /* * XXX: from gcc 6.2 manual: * Note, the ms_abi attribute for Microsoft Windows 64-bit targets @@ -47,8 +45,12 @@ #define EFIABI_ATTR __attribute__((ms_abi)) #endif +#ifdef _KERNEL +#include + #define EFI_TIME_LOCK() mtx_lock(&atrtc_time_lock); #define EFI_TIME_UNLOCK() mtx_unlock(&atrtc_time_lock); #define EFI_TIME_OWNED() mtx_assert(&atrtc_time_lock, MA_OWNED); +#endif #endif /* __AMD64_INCLUDE_EFI_H_ */ From owner-freebsd-current@freebsd.org Mon Oct 2 11:58:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F168AE3D7B3 for ; Mon, 2 Oct 2017 11:58:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0061.outbound.protection.outlook.com [104.47.33.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED7D653AA; Mon, 2 Oct 2017 11:58:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB1511.CANPRD01.PROD.OUTLOOK.COM (52.132.82.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 11:57:59 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Mon, 2 Oct 2017 11:57:59 +0000 From: Rick Macklem To: "cem@freebsd.org" CC: "freebsd-current@freebsd.org" Subject: Re: panic in AcpiOsGetTimer during boot. Thread-Topic: panic in AcpiOsGetTimer during boot. Thread-Index: AQHTOwGAIy8rz5AXN0ORsi5i7QtdWaLP1EeAgACgepY= Date: Mon, 2 Oct 2017 11:57:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1511; 6:+t4+EI8zgsmR0PgcO59As/Ej19oiR3TfpDBYDKdvCfoPPY/3ijsmLKVxUsDzM7othmmdsMbKSlWzAH4x/h2Us6IXdNRQu10DDtPODrMOxo8H2FEDai5FqOy2u6mRLBCWKEMJOkf1LE4z+7qkrdDJQ+QN+09K37wUwVPbUpBjW7X+BxnW2+dhaCU/pi+ZV201G2ILUyCM1bW855fCjF09rd9PDEu3R9aNqJdzp9lcmeKczgqP2KB1hj0zw3pFJiHeRqdGhyZrOxJWqYoXos422nP8C+1YmHgpBDOb5koDRt3kXWhfWJZLMa5rlJF5rpLkM+C9dhVChBqQiU+jF8bnbQ==; 5:h6Nv8AY8LUFALCb5XpFH5VuazsW8bA5GC9HojBzF5AjLRqVCMiDY6MND/JRZM3dR5MdKGe3CT7Dy1Cu9P3eht705xRCtDtsFiydCN/97LQj7Qlv63Ej/srdgUrZJs2pbgJs18MTdunU1VPZ0LeM39bwmNHufrlpx8CeWN9b1EGo=; 24:f1qfFsr+whlg+ckwZGWiLn3OxuNDw5JzhN7vH2rbxtYxJAvDvOyT3qQs2rpEs4ss9OLN2kzFlTErDwnGVyyFdad0PqxcC/6VRJqAP13nOFs=; 7:SYxKv7Hjyl9MUaKMESx+j0NWqjHeO9tHB3tGk0PHaYxfr+nGpuJF+bo3Mcl6DPmV7RdkSWxDMO/muME5Z+bYi7YjC/NALVyeyRfwRGIwmCCQ7wX5fsnlSINu4xI+w/PfVs9wb+yfi2e4I2P3ecGF2FKypTthCxUpfTntvj+gUH74/Qn+dMWtRIo9Oc1tTT2VgoG7o5WsuMKEYoK0mN0qv81tmhVev7MYxegsI9zQulY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4eecae0e-365d-4fbb-eb8f-08d5098cd3a2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB1511; x-ms-traffictypediagnostic: YQXPR0101MB1511: x-exchange-antispam-report-test: UriScan:(75325880899374); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB1511; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB1511; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(6029001)(346002)(376002)(24454002)(189002)(377454003)(13734003)(199003)(229853002)(55016002)(54356999)(25786009)(5660300001)(3660700001)(9686003)(14454004)(74482002)(33656002)(76176999)(6436002)(50986999)(6306002)(786003)(1730700003)(2900100001)(8676002)(81156014)(450100002)(53936002)(2906002)(81166006)(3280700002)(8936002)(4326008)(97736004)(316002)(6506006)(5250100002)(102836003)(2501003)(86362001)(5890100001)(105586002)(2351001)(305945005)(2950100002)(114624004)(106356001)(6916009)(5640700003)(478600001)(7696004)(189998001)(68736007)(966005)(101416001)(6246003)(53546010)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB1511; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 11:57:59.2753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1511 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 11:58:03 -0000 Conrad Meyer wrote: > Are you running into the same issue reported on this svn-src thread? > https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151775.htm= l Yep, same panic(). > I believe jkim has reverted the change in a subsequent revision (r324136)= . I'll try a post-r324136 kernel. If it still panics, I'll post again. Thanks, rick > Best, > Conrad On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem wrote: > Hi, > > I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day= old) > kernel. When I delete the KASSERT(), the kernel boots and seems to work o= k. > (This is the AcpiOsGetTimer() in sys/dev/acpica/Osd/OsdSchedule.c. There = also > seems to be one of these functions under contrib.) > > Here is my dmesg after boot, if it helps indicate why this is called when= "cold" > is still set. (I've marked where the dmesg ends when it Panics if the KAS= SERT() > is enabled.) > > dmesg after booting: > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #1: Sun Oct 1 09:48:42 EDT 2017 > root@nfsv4-newerlap.rick.home:/sub1/sys.headsep30/amd64/compile/GENER= IC amd64 > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (2294.84-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x306a9 Family=3D0x6 Model=3D0x3a Step= ping=3D9 > Features=3D0xbfebfbff > Features2=3D0x7fbae3bf > AMD Features=3D0x28100800 > AMD Features2=3D0x1 > Structured Extended Features=3D0x281 > XSAVE Features=3D0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory =3D 17179869184 (16384 MB) > avail memory =3D 16518905856 (15753 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: <_ASUS_ Notebook> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads > random: unblocking device. > arc4random: no preloaded entropy cache > ioapic0 irqs 0-23 on motherboard > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #4 Launched! > **** dmesg ends here when in KASSERT() panics. > SMP: AP CPU #5 Launched! > SMP: AP CPU #2 Launched! > Timecounter "TSC-low" frequency 1147419696 Hz quality 1000 > random: entropy device external interface > netmap: loaded module > [ath_hal] loaded > module_register_init: MOD_LOAD (vesa, 0xffffffff80f779d0, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > kbd1 at kbdmux0 > nexus0 > vtvga0: on motherboard > cryptosoft0: on motherboard > acpi0: <_ASUS_ Notebook> on motherboard > acpi_ec0: port 0x62,0x66 on acpi0 > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: registered as a time-of-day clock, resolution 1.000000s > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xe000-0xe07f mem 0xf6000000-0xf6f= fffff,0xf0000000-0xf3ffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on p= ci1 > vgapci0: Boot video device > hdac0: mem 0xf7080000-0xf7083fff irq 17 at = device 0.1 on pci1 > xhci0: mem 0xf7300000-0xf730ffff= irq 16 at device 20.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0: waiting for BIOS to give up control > xhci0: Port routing mask set to 0xffffffff > usbus0 on xhci0 > usbus0: 5.0Gbps Super Speed USB v3.0 > pci0: at device 22.0 (no driver attached) > ehci0: mem 0xf7318000-0xf73183ff= irq 16 at device 26.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > usbus1: 480Mbps High Speed USB v2.0 > hdac1: mem 0xf7310000-0xf7313fff irq= 22 at device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > iwn0: mem 0xf7200000-0xf7201fff irq 17 a= t device 0.0 on pci3 > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > pcib4: irq 19 at device 28.3 on pci0 > pci4: on pcib4 > alc0: port 0xd000-0xd07f mem = 0xf7100000-0xf713ffff irq 19 at device 0.0 on pci4 > alc0: 11776 Tx FIFO, 12032 Rx FIFO > alc0: Using 1 MSI message(s). > miibus0: on alc0 > atphy0: PHY 0 on miibus0 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-= FDX, 1000baseT-FDX-master, auto, auto-flow > alc0: Using defaults for TSO: 65518/35/2048 > alc0: Ethernet address: 10:bf:48:23:08:56 > ehci1: mem 0xf7317000-0xf73173ff= irq 23 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > usbus2: 480Mbps High Speed USB v2.0 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port 0xf070-0xf077,0xf0= 60-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xf7316000-0xf73167= ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich2: at channel 2 on ahci0 > ahciem0: on ahci0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > est0: on cpu0 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Mon Oct 2 13:19:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFBB2E3F4C1; Mon, 2 Oct 2017 13:19:11 +0000 (UTC) (envelope-from elenamihailescu22@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 6C73767E83; Mon, 2 Oct 2017 13:19:11 +0000 (UTC) (envelope-from elenamihailescu22@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id u130so8924848oib.11; Mon, 02 Oct 2017 06:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/shr94vmU5vdgfzTCdDKPArnKI8lyf3v79gPhyBVprY=; b=tvZ4Gj6A3FddrHi3XwhXSe/aA6M3jfK2uZQ49rzkesGGqYNTVqnvn3hDZNRVq7fOSg jwZ38tC8YGCW4ViWnYeL9js7q06KKvMGAk6TjrbDi+qEVBhEvREQGpEPAVpi7ilWAsbw iyYmCHO/E4rtH8hNT1NfQN2z68Bb2F/IFfwMusLiHp0yVEXfJID/+q1iY1CYFEmMxS+I oXopkHDhc8dA+c9ftk2mj2xClVwvWl49bs2j82nc69kfB63mooLaLdimo4BF2gBpMK9G wyYzRoA2crUHoP9Hj7uJCL9TAaWoiHKumJUlM3mYOA5PP4oMeXTtgTTyOHdtA3wEuiZu AEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/shr94vmU5vdgfzTCdDKPArnKI8lyf3v79gPhyBVprY=; b=fhqoL9nMa45vQxd9ObEG7qernoo3WrUbVMsMEqoOHqfZp8Ta92j+u05ombxY5Bq9uD iyIPANev1ra9m7/BHEPowNZ5enmEcffi7KR45hqoHDkcONH3pr3KkB8t3kk1zjXoWHax KVxqXmsove7oFS/zhCTcACxrp3PLKUQwI9yzohhg9Dqfz+gCEOjl9NBcXtFKVgFe18tI B7rJmB+a+mAuYiQJ4lzQGhU/IOOxPfGzRByQcEy0FVC0Xv+uLydA/DplD1A/yCl2OxlH 97C/ufYTh6tlQ2LibLvZbkxUOYDD7TKYAMjd7/wGUa13+5iU+Pfd4pFM/W2vRzQfGa7S nQmA== X-Gm-Message-State: AMCzsaViZy56OFkmU9HUthwUdtfIdaDkBYyP8mtZsf+apep7ifB35d7U td7N19X5FgnftXT7F8bYem/vCjUSxDB/Sa078Eg3EA== X-Google-Smtp-Source: AOwi7QAz5PwzQ6GwgPyIwpRei73kfaQ4TW1EYuhNIdWGN1+NBf9+9rlekXeSx9eftb9xBxRG8GGtqtYQDOFq3zZRvHA= X-Received: by 10.202.223.8 with SMTP id w8mr6474055oig.17.1506950350402; Mon, 02 Oct 2017 06:19:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.36.228 with HTTP; Mon, 2 Oct 2017 06:19:09 -0700 (PDT) From: Elena Mihailescu Date: Mon, 2 Oct 2017 16:19:09 +0300 Message-ID: Subject: ATAPI_IDENTIFY error while trying to install FreeBSD on Acer Veriton M421G To: freebsd-amd64@freebsd.org, freebsd-current , freebsd-virtualization@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:19:11 -0000 Hello! I am trying to install FreeBSD 12.0-CURRENT / FreeBSD 11.1-RELEASE on an Acer Veriton M421G with AMD Athlon II X2 250 processor and M2N rev 1.02g motherboard. While booting from USB, it does not recognize the harddisk (a SATA HDD) and I cannot continue the process of installation. I get the following error periodically : ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00001000 tfd 50 serr 00000000 cmd 00046c17 (aprobe0:ahcich1:0:0:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ahcich1:0:0:0): CAM status: Command timeout (aprobe0:ahcich1:0:0:0): Error 5, Retries exhausted A proper image with error showed on screen is here [1] and a dmesg output obtained using an USB device with FreeBSD installed on it can be found here [2]. I mention that on this HDD I have successfully installed Linux Mint Cinnamon 17.3 64 bit. What I already did/checked: - I checked SATA cables (DVD-ROM is connected as well on SATA and works fine - I can boot from a CD and I tried to switch HDD and DVD-ROM cables). - I tried another SATA HDD - I tried different versions of FreeBSD (bootable USB and ISO CDs) - Modify in BIOS the SATA mode: Native, Legacy and AHCI. - I managed to install FreeBSD 11.1-Release on another USB device - unfortunately this is not a solution - it runs very very slow. Also, this way, I managed to get a dmesg output [2]. - I updated the BIOS. - I tried what is described here [3] - The only way this error is not displayed is when I disconnect both HDD and DVD-ROM. - BIOS system info is here [4] Does anyone knows how I can solve this issue? Thanks, Elena [1] https://drive.google.com/open?id=0B8qXIRloK7xeZk0zZFhlWFJWU3M and https://drive.google.com/open?id=0B8qXIRloK7xeUlJwSTZUaXIxYlE [2] https://drive.google.com/open?id=0B8qXIRloK7xeWGR3WXZFSXVkaFk [3] https://lists.freebsd.org/pipermail/freebsd-questions/2003-August/015096.html [4] https://drive.google.com/open?id=0B8qXIRloK7xedVpYb0NuWVB6ODg From owner-freebsd-current@freebsd.org Mon Oct 2 20:07:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 892C9E26A3C for ; Mon, 2 Oct 2017 20:07:20 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 720D676328 for ; Mon, 2 Oct 2017 20:07:20 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.139.75] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 7bae4a79 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Mon, 2 Oct 2017 13:07:19 -0700 (PDT) To: freebsd-current@freebsd.org From: Pete Wright Subject: building world via ccache broken? Message-ID: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> Date: Mon, 2 Oct 2017 13:07:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 20:07:20 -0000 hey there, i've been unable to buildworld using ccache for a while. initially i assumed it was due to some incompatibilities on the drm-next branch which i was running, but i've since cut over to CURRENT and am still having issues. running "make buildworld" i am running into this exception: /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no member named 'fs_metackhash' in 'struct fs' if ((fs->fs_metackhash & CK_CYLGRP) != 0) { ~~ ^ full exception here: https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61 I am going to re-run this w/o ccache - to verify that this is a ccache related issue. I guess my first question - is anyone else using ccache successfully? thanks in advance! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Oct 2 22:23:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F918E28F00 for ; Mon, 2 Oct 2017 22:23:34 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5A37DBB7 for ; Mon, 2 Oct 2017 22:23:34 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.139.75] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id eca237d7 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Mon, 2 Oct 2017 15:23:32 -0700 (PDT) Subject: Re: building world via ccache broken? To: freebsd-current@freebsd.org References: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> From: Pete Wright Message-ID: Date: Mon, 2 Oct 2017 15:23:32 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 22:23:34 -0000 On 10/02/2017 13:07, Pete Wright wrote: > hey there, > i've been unable to buildworld using ccache for a while. initially i > assumed it was due to some incompatibilities on the drm-next branch > which i was running, but i've since cut over to CURRENT and am still > having issues.  running "make buildworld" i am running into this > exception: > > /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no > member named 'fs_metackhash' in 'struct fs' >         if ((fs->fs_metackhash & CK_CYLGRP) != 0) { >              ~~  ^ > > > full exception here: > https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61 > > I am going to re-run this w/o ccache - to verify that this is a ccache > related issue.  I guess my first question - is anyone else using > ccache successfully? > fwiw building the world without ccache works as expected.  perhaps my make.conf is not correctly configured? $ cat /etc/make.conf .if !defined(NO_CCACHE)   CC= /usr/local/libexec/ccache/world/cc   CXX= /usr/local/libexec/ccache/world/c++ .endif cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Oct 2 23:36:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47BA1E2A1A0 for ; Mon, 2 Oct 2017 23:36:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C83F7FDF3; Mon, 2 Oct 2017 23:35:59 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.139.75] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id fbb7376e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 2 Oct 2017 16:35:58 -0700 (PDT) Subject: Re: building world via ccache broken? To: Matt Joras , freebsd-current@freebsd.org References: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> From: Pete Wright Message-ID: Date: Mon, 2 Oct 2017 16:35:58 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 23:36:00 -0000 On 10/02/2017 16:33, Matt Joras wrote: > On 10/02/2017 15:23, Pete Wright wrote: >> >> On 10/02/2017 13:07, Pete Wright wrote: >>> hey there, >>> i've been unable to buildworld using ccache for a while. initially i >>> assumed it was due to some incompatibilities on the drm-next branch >>> which i was running, but i've since cut over to CURRENT and am still >>> having issues.  running "make buildworld" i am running into this >>> exception: >>> >>> /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no >>> member named 'fs_metackhash' in 'struct fs' >>>         if ((fs->fs_metackhash & CK_CYLGRP) != 0) { >>>              ~~  ^ >>> >>> >>> full exception here: >>> https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61 >>> >>> I am going to re-run this w/o ccache - to verify that this is a >>> ccache related issue.  I guess my first question - is anyone else >>> using ccache successfully? >>> >> fwiw building the world without ccache works as expected.  perhaps my >> make.conf is not correctly configured? >> >> $ cat /etc/make.conf >> .if !defined(NO_CCACHE) >>   CC= /usr/local/libexec/ccache/world/cc >>   CXX= /usr/local/libexec/ccache/world/c++ >> .endif >> >> cheers, >> -pete >> > Someone can correct me if I'm wrong but I believe the current "correct" > way to get ccache builds is WITH_CCACHE_BUILD set in src.conf. > src.conf(5) seems to indicate as much as well. To answer your question, > yes, I am I'm sure many others are building world on HEAD with ccache > without issue. thanks, i had another person point me in this direction - and after reading the man page it does indeed clearly state as much :) what had tripped me up is that the ccache portfile installs: /usr/local/share/doc/ccache/ccache-howto-freebsd.txt which does not mention src.conf, but states: To use ccache for base add the following to /etc/make.conf. You can replace cc and c++ with the compilers of your choice. (remember that only GCC and Clang can build world and kernel) .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) .if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc) CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} .endif .endif if i'm able to successfully build my world and kernel via src.conf i'll file a PR against the ccache port. cheers! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Oct 3 01:08:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E951E2BD02 for ; Tue, 3 Oct 2017 01:08:55 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.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 7D61B81FF2 for ; Tue, 3 Oct 2017 01:08:54 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-qk0-f169.google.com with SMTP id o187so4780814qke.7 for ; Mon, 02 Oct 2017 18:08:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=npQ54y9f/vVc1948sP8c7TFGMNdCIpxXV5Iy5s1rrgM=; b=jrqSBK2/3YkyUI4qGPwxwGe1Ql3Re0QxOncdGzWPk8okZGynd+uG4gt5ZHiQa3gWqq BhvrV6rAiwVkgFMadxdXjpiKHz74JBEbVpjBSDRnFnpsQAw0RoZ7xvfyvy9e0l6Ckp8o NQ8zouRvfSTyTiRz19oMcYWKmT6WzWkG2eTvgTjTorcgzfTAyfaj2NPFxk01xXdIlyTQ EAneVVlD6egVsZqluV7Uem6cG4A4Dm5n08TL7opicIDrDK09+EHtuE6KmZKWmrcdfyNP EyStkihMEwuYatkimvn/7W8Pyc8T8DRjhdWItin1brHk8RpY2fPDu4znB9m90z8NaP4e Ml+g== X-Gm-Message-State: AMCzsaWOLvGwbJsdTVApwYGKAbQ5BM7pG/d71a8be+N6mngdjFm8+JQR k66y/SIXO5R1LCyIhopNEMwBQa0/ X-Google-Smtp-Source: AOwi7QCnQEqPtHqVEqBOnbqFjo12qHB6bJxiOLcqlXbMVdIHk7lyrsv/OKq4cWjE/kCYiyTDT7nnVQ== X-Received: by 10.55.178.65 with SMTP id b62mr17749500qkf.348.1506987187183; Mon, 02 Oct 2017 16:33:07 -0700 (PDT) Received: from [192.168.2.122] (71-212-87-125.tukw.qwest.net. [71.212.87.125]) by smtp.gmail.com with ESMTPSA id w46sm7678592qta.84.2017.10.02.16.33.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 16:33:06 -0700 (PDT) Subject: Re: building world via ccache broken? To: Pete Wright , freebsd-current@freebsd.org References: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> From: Matt Joras Message-ID: Date: Mon, 2 Oct 2017 16:33:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 01:08:55 -0000 On 10/02/2017 15:23, Pete Wright wrote: > > > On 10/02/2017 13:07, Pete Wright wrote: >> hey there, >> i've been unable to buildworld using ccache for a while. initially i >> assumed it was due to some incompatibilities on the drm-next branch >> which i was running, but i've since cut over to CURRENT and am still >> having issues.  running "make buildworld" i am running into this >> exception: >> >> /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no >> member named 'fs_metackhash' in 'struct fs' >>         if ((fs->fs_metackhash & CK_CYLGRP) != 0) { >>              ~~  ^ >> >> >> full exception here: >> https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61 >> >> I am going to re-run this w/o ccache - to verify that this is a >> ccache related issue.  I guess my first question - is anyone else >> using ccache successfully? >> > > fwiw building the world without ccache works as expected.  perhaps my > make.conf is not correctly configured? > > $ cat /etc/make.conf > .if !defined(NO_CCACHE) >   CC= /usr/local/libexec/ccache/world/cc >   CXX= /usr/local/libexec/ccache/world/c++ > .endif > > cheers, > -pete > Someone can correct me if I'm wrong but I believe the current "correct" way to get ccache builds is WITH_CCACHE_BUILD set in src.conf. src.conf(5) seems to indicate as much as well. To answer your question, yes, I am I'm sure many others are building world on HEAD with ccache without issue. From owner-freebsd-current@freebsd.org Tue Oct 3 03:16:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96A5AE2EDC7 for ; Tue, 3 Oct 2017 03:16:07 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5419426A6 for ; Tue, 3 Oct 2017 03:16:07 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.208] (cpe-23-242-94-236.socal.res.rr.com [23.242.94.236]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 073032ff TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Mon, 2 Oct 2017 20:16:05 -0700 (PDT) Subject: Re: building world via ccache broken? To: freebsd-current@freebsd.org References: <0e4e8110-9b79-2010-852c-3815885d3523@nomadlogic.org> From: Pete Wright Message-ID: Date: Mon, 2 Oct 2017 20:16:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 03:16:07 -0000 On 10/02/2017 16:35, Pete Wright wrote: > > > On 10/02/2017 16:33, Matt Joras wrote: >> On 10/02/2017 15:23, Pete Wright wrote: >>> >>> On 10/02/2017 13:07, Pete Wright wrote: >>>> hey there, >>>> i've been unable to buildworld using ccache for a while. initially i >>>> assumed it was due to some incompatibilities on the drm-next branch >>>> which i was running, but i've since cut over to CURRENT and am still >>>> having issues.  running "make buildworld" i am running into this >>>> exception: >>>> >>>> /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no >>>> member named 'fs_metackhash' in 'struct fs' >>>>          if ((fs->fs_metackhash & CK_CYLGRP) != 0) { >>>>               ~~  ^ >>>> >>>> >>>> full exception here: >>>> https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61 >>>> >>>> I am going to re-run this w/o ccache - to verify that this is a >>>> ccache related issue.  I guess my first question - is anyone else >>>> using ccache successfully? >>>> >>> fwiw building the world without ccache works as expected. perhaps my >>> make.conf is not correctly configured? >>> >>> $ cat /etc/make.conf >>> .if !defined(NO_CCACHE) >>>    CC= /usr/local/libexec/ccache/world/cc >>>    CXX= /usr/local/libexec/ccache/world/c++ >>> .endif >>> >>> cheers, >>> -pete >>> >> Someone can correct me if I'm wrong but I believe the current "correct" >> way to get ccache builds is WITH_CCACHE_BUILD set in src.conf. >> src.conf(5) seems to indicate as much as well. To answer your question, >> yes, I am I'm sure many others are building world on HEAD with ccache >> without issue. > > thanks, i had another person point me in this direction - and after > reading the man page it does indeed clearly state as much :) > > what had tripped me up is that the ccache portfile installs: > /usr/local/share/doc/ccache/ccache-howto-freebsd.txt > > which does not mention src.conf, but states: > > > To use ccache for base add the following to /etc/make.conf. > You can replace cc and c++ with the compilers of your choice. > (remember that only GCC and Clang can build world and kernel) > > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) > .if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc) > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} > .endif > .endif > > > if i'm able to successfully build my world and kernel via src.conf > i'll file a PR against the ccache port. > > cheers! > -pete > I can verify that this works on my system, firing off a PR now to the ports team to update documentation shortly :) thanks for the input everyone. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Oct 3 08:51:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E011CE356BB; Tue, 3 Oct 2017 08:51:41 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4600B6AF4B; Tue, 3 Oct 2017 08:51:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.72.205]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwrPM-1dFDci1tsG-016Rq2; Tue, 03 Oct 2017 10:51:32 +0200 Date: Tue, 3 Oct 2017 10:51:24 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Ports Subject: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64? Message-ID: <20171003105124.6b661017@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/8_/KV1nqqQOtqpC05WlGfe."; protocol="application/pgp-signature" X-Provags-ID: V03:K0:RR8I8SMQhgwBE9OSDwHK9lXN8SHbo8I3u3rU+7yNbXQDiejtIGw 3aL5nkzjbtl83GveqhI+XG7/p2h+CSk66RWMdDqNTe2I8OrlTiIEUtH+sw+X6lMXf1UcnVE YgbIRJAT1HvMswBFKRzgRIdOhcGqw3XSUHNtlc6VEIrJsfYCLtMZlky8qiiixx4pXga4Byh AxISxoAKI1HlyPsgcqYUA== X-UI-Out-Filterresults: notjunk:1;V01:K0:vTYWvkg4ytc=:ij+GeipPoqU1EFhEElQpo7 8Ux6Jb9yluXQ2vLfqB79nadbNht8q6MrO39JeGTeJ0lN7F9HTq00m3jq8OThInAjgb7SmMQuC vDu+jJ0wsjzLjzJ23uRYxekC6R0/0Ur9jpYrFDhDvCCaRzF9fUa7lUXgEkP9+F2g6p19g+pzg gyP849EjhB+6wmT3G/v1stX43wHwc5Z0xlOO3foXPTAjNj2Y4dQms1b0B5Y/jlm5czz+BuRI8 35tBE1q5+T45ut/3mMuwfaSuy0YZ6k0bmZxAwlxdBRMwmfF3hp7dxZl7nv6kx6ufiUOhBS5kN 2a3j3QJfyNVpEeP1n0b+MFEGnNFYlrzHlwVOyee4L9IhlfZkNtK1CpM8FLEwgIaHBKIoDaoBF 5iMy9hSljwf1O40a7KZ4wR0k/9cu2j21FOc3dpbuNMZMqxcxv3Om1C+B7GvwgYuOpc8tP3d41 25qC98UFy3NNg9re4QhOEd3tPCSp3U+ydgN1+8EVbFeOvfLCOqwrXn5NhyF041ckpZKJlRVHr pOzTdxTdajdwbT2mnor39luoQxdyEBg4+fCMLQ+lVzPOxvL6hyI9EMdWiJCqfS6N8778MK4Gm dmpAmXbzMzE5fNqpnrUIP7QD66UPej74pD+HHIB4A00dkMdJLI7LyQ7lioi3npLeG8T5Dzf1j 58DFFrBhD7C75VZJrKdX66haYDU/ryJzsOajRo/LWa3sLe5majQ3pZDSdhrOv8XF3mlJY1eJ4 Wyz6UMuNgYwXgxuUfi5JCANDnMwEPw3mQPpnCAQx9i2/05d16cFh3rUkC+TlrTymF7Wfdky3s l9gbrab8tOSJL0h3/URXrRjt087IA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 08:51:42 -0000 --Sig_/8_/KV1nqqQOtqpC05WlGfe. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeB= SD base, it seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD worl= d uses x86:64, FreeBSD is using amd64, but why is this used inconsistently all over the pl= aces? I run into trouble setting up some package- and base-servers and ran into t= he problem when deleting - not thinking of this discovered inconsistency - some links = on the servers regarding FreeBSD:12:x86:64 (the same is for 11-STABLE). Can someone shed some light onto this?=20 What am I supposed to use now? The handbook referes to amd64, so I thought = poudriere would, too.=20 Thanks in advance, oh --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/8_/KV1nqqQOtqpC05WlGfe. Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdNPjAAKCRDS528fyFhY lFgbAgCQ2dz1RSaZ2eAEqBpyQV5Nde85edLswg45tkw2vc1eby6vVoHuFk0GFqxj uscuxrxtSMFxXtwBHobuG9nGXJVuAf0WO0xQUWWn2ikfZgvLWn3kzxtBy/vi8vnD 7K3IeBuamFo8rzixGtv0U7kXhcnpT83UpAcr2WxrMo/pJwednPZM =Gc9Z -----END PGP SIGNATURE----- --Sig_/8_/KV1nqqQOtqpC05WlGfe.-- From owner-freebsd-current@freebsd.org Tue Oct 3 10:43:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4F41E38160; Tue, 3 Oct 2017 10:43:34 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB0B46E592; Tue, 3 Oct 2017 10:43:34 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dzKfd-0001tg-Kn; Tue, 03 Oct 2017 12:43:25 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dzKfd-0004KK-Ik; Tue, 03 Oct 2017 12:43:25 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Tue, 03 Oct 2017 10:43:25 GMT From: "Jeffrey Bouquet" To: "O. Hartmann" CC: "FreeBSD CURRENT" , "FreeBSD Ports" Subject: Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64? Date: Tue, 03 Oct 2017 03:43:25 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <20171003105124.6b661017@thor.intern.walstatt.dynvpn.de> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 10:43:35 -0000 On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann" w= rote: > When using "poudriere", it seems ABI is freebsd:12:x86:64. When using Fre= eBSD base, it > seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD wo= rld uses x86:64, > FreeBSD is using amd64, but why is this used inconsistently all over the = places? >=20 > I run into trouble setting up some package- and base-servers and ran into= the problem > when deleting - not thinking of this discovered inconsistency - some link= s on the servers > regarding FreeBSD:12:x86:64 (the same is for 11-STABLE). >=20 > Can someone shed some light onto this?=20 >=20 > What am I supposed to use now? The handbook referes to amd64, so I though= t poudriere > would, too.=20 >=20 > Thanks in advance, >=20 > oh > --=20 > O. Hartmann >=20 > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s. 4 BDSG). [ not using poudriere yet ] /me too I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base= , ] fourth: hard coded DESPITE the above in the current DB in var/db/pkg? fifth: derived somehow from uname -a? here: freebsd:12:x86:32 ... when this issue resolved, could it please be added to 'man pkg|poudrier= e|syntch|portmaster?|portupgrade? [ the latter two when developed further = ]'= From owner-freebsd-current@freebsd.org Tue Oct 3 11:08:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B59FEE38A60; Tue, 3 Oct 2017 11:08:54 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B0FE6F234; Tue, 3 Oct 2017 11:08:54 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dzL4H-0006SV-Uv; Tue, 03 Oct 2017 13:08:53 +0200 Date: Tue, 3 Oct 2017 13:08:53 +0200 From: Kurt Jaeger To: "O. Hartmann" Cc: FreeBSD CURRENT , FreeBSD Ports Subject: Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64? Message-ID: <20171003110853.GO86601@home.opsec.eu> References: <20171003105124.6b661017@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171003105124.6b661017@thor.intern.walstatt.dynvpn.de> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 11:08:54 -0000 Hi! > When using "poudriere", it seems ABI is freebsd:12:x86:64. Where do you get that value from ? If I access a repo, I access e.g. https://repo.opsec.eu/${ABI} and ABI maps to FreeBSD:12:amd64 -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Tue Oct 3 12:04:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 412F1E3A7EC; Tue, 3 Oct 2017 12:04:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A115C714C0; Tue, 3 Oct 2017 12:04:19 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.192.150]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbKXI-1dimTz1oAO-00Ijxl; Tue, 03 Oct 2017 14:04:07 +0200 Date: Tue, 3 Oct 2017 14:03:59 +0200 From: "O. Hartmann" To: Kurt Jaeger Cc: "O. Hartmann" , FreeBSD CURRENT , FreeBSD Ports Subject: Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64? Message-ID: <20171003140359.1d2a477e@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171003110853.GO86601@home.opsec.eu> References: <20171003105124.6b661017@thor.intern.walstatt.dynvpn.de> <20171003110853.GO86601@home.opsec.eu> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/icgBS3Hmy3sqq1+LmbsYnTw"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:HsnYvhTLG0B/kf0o7k+2N3dPmb4LeSAqeAn3Yr8lotRS5n2XXdA ltj94Be28VBJYftM1QWcM8JzmZ6sGYRnCoftliHP+8YFD/wKyn85Huc6WoZjL2GioOZf4u3 r+wPXITDcGs1dam36OezWelHFkMwJjZFa/XgkTPi4XomXVt03h7RT4nxIaFdzhJxLY6+C+T xCR4hQi/AZn4312El//tA== X-UI-Out-Filterresults: notjunk:1;V01:K0:uYT23rge5/Q=:N7r4agOIphrFZJufyNFHUK XUmttk1hpFeRZa0r6FiSDIlrGdwfLGL3Nq5oKKQ4QGJO6aSZAlJ2gEL4np+C6/N+G0doaYEFW 73lZVgfUpQu25ccEJnoEL6EJTRXm5o03HmU/7Sr2x5ug7s/s+yiQaHvD+t3FdPHjOOlIWO/vc RPhoh4qUUd9USc9l6/6qsEZXbgULJr7VsLlPzCA7SuvtgikotxaYTUnVJCUx7GkOqfQ1m6dIU YJmFJnYXc+a07yKWBgDPf9NWgiTn1muzfD//jLAucDuX4TW4USdU+VjI3b9+oHPHC0Mgk4bJX QZxOGr2zAygRI//T7Y1jlpb6+dt2lREgDsBYEva+Tf63iCrB5jC2rZerLbGj3XxPvCKYMzge7 m32CD1QYc7lo6BnuMVx1A7oZc/Hn5lBhU9AZPM7rHOXcvf8O90vRf44W1vhqFCABru5/KATLB GvjoUhLLaYQd0iOsT3YUCTiyFRJpYM5AZ9IpDkCHbJSuco0qK0RwgI75O1jZhHD+h6jGY5tz2 GT+4v74mi6RZMQUeHytmfrsvz7UwMSp0wWOfGFzv28565wfnllzpKDbN7tGT3eGaP6OumyBlR fWf4ZHQvDh5fRTF5LH0cU1Up2q9nA0nLjEQUJatZB4s9LHEg5AOtbdFM7Z5Q7qfwMfHggvu1v os5J9Ejp4Tq6UcwdyhJU9Mm6MxEhny7cu28jssUKk0YadwIT9l/yRLOTGVqGLSz81wLDmfoKL L+tIP+P/2H01udMYXhPi4XYvbhuchf768kadBDk7DHX31OkK1VRlvU+NPdIJmUFueeYofe3ir gyYtTOM04iiG6lrexVsgsGqEQLLAw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 12:04:20 -0000 --Sig_/icgBS3Hmy3sqq1+LmbsYnTw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 3 Oct 2017 13:08:53 +0200 Kurt Jaeger schrieb: > Hi! >=20 > > When using "poudriere", it seems ABI is freebsd:12:x86:64. =20 As I wrote: poudriere repo. >=20 > Where do you get that value from ? If I access a repo, > I access e.g. >=20 > https://repo.opsec.eu/${ABI} >=20 > and ABI maps to >=20 > FreeBSD:12:amd64 >=20 --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/icgBS3Hmy3sqq1+LmbsYnTw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdN8rwAKCRDS528fyFhY lFjTAf9UbzaQuXUqb9+jKbivKZGzZy2IBCX7eqD693gt5mlqVHpiJ4GThKgfxEPs irMFCfTaJtVWLxybzWVZ3pfsa9rYAf93+4oJcx0GdopBp72bWS0VgkvklQPXsxuO fe5cXBLZPMXe+ULGWLVznia+R8rDbu6Lov1DnHMQrgFCmlMlY3Jn =9g/7 -----END PGP SIGNATURE----- --Sig_/icgBS3Hmy3sqq1+LmbsYnTw-- From owner-freebsd-current@freebsd.org Tue Oct 3 16:19:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3451FE4190B; Tue, 3 Oct 2017 16:19:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 127537FA95; Tue, 3 Oct 2017 16:19:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-131-198.dyn.iinet.net.au [106.68.131.198]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v93GIp1m039818 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Oct 2017 09:18:55 -0700 (PDT) (envelope-from julian@freebsd.org) To: "ports@FreeBSD.org" , freebsd-current From: Julian Elischer Subject: anyone know how to get rid of this error? (10.4/Gcc vs binutils port) Message-ID: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> Date: Wed, 4 Oct 2017 00:18:46 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:19:03 -0000 Our 10.4 system is using gcc (for now). when we compile the devel/binutils port, we get a failure with a bunch of these errors: `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE]' of aarch64.o `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE]' of aarch64.o I managed to defeat these one before but I forget how. possibly the answer is to use clang/clang++ for this item but I tried defining CC and CXX  to clang/clang++ in the Makefile but that didn't seem to help there's probably a USE_CLANG option or something that I haven't seen. From owner-freebsd-current@freebsd.org Tue Oct 3 16:56:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB77BE425F5 for ; Tue, 3 Oct 2017 16:56:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 CF218810ED for ; Tue, 3 Oct 2017 16:56:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c672136a-a85b-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c672136a-a85b-11e7-a937-4f970e858fdb; Tue, 03 Oct 2017 16:56:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v93GuALN001521; Tue, 3 Oct 2017 10:56:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507049770.86205.16.camel@freebsd.org> Subject: Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port) From: Ian Lepore To: Julian Elischer , "ports@FreeBSD.org" , freebsd-current Date: Tue, 03 Oct 2017 10:56:10 -0600 In-Reply-To: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> References: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:56:19 -0000 On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote: > Our 10.4 system is using gcc (for now). > > when we compile the devel/binutils port, we get a failure with a > bunch  > of these errors: > > > `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section  > `.rodata' of aarch64.o: defined in discarded section  > `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__ > N_110Stub_tableILi64ELb1EEE]'  > of aarch64.o > `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section  > `.rodata' of aarch64.o: defined in discarded section  > `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__ > N_110Stub_tableILi64ELb0EEE]'  > of aarch64.o > > > I managed to defeat these one before but I forget how. > > possibly the answer is to use clang/clang++ for this item but I > tried  > defining CC and CXX  to clang/clang++ in the Makefile but that > didn't  > seem to help > > there's probably a USE_CLANG option or something that I haven't seen. We ran into the same thing recently at $work.  The root cause for us involved having same-named classes in anonymous namespaces in different compilation units.  The classes made reference to something that was declared extern "C", bringing into play some rules about how C things in anon namespaces really refer to the same global C object outside of any namespace.  Then link-time optimization led to discarding the object from one compilation unit, and that somehow resulted in discarding the referenced extern "C" thing completely, even though it was still referenced from the non-discarded instance of an object from a different compilation unit.  Phew. The same code has no problems with clang on freebsd 11, just with gcc on 10.3.   So, for us the fix was a bit heavy-handed: we just renamed one of the classes involved in the problem so that there were no longer any same- named classes in anon namespaces in separate compilation units.  Probably not a good option for you.  A fix involving compile options might result in not discarding unreferenced segments at all, and with templated code that might result in huge binaries. Mixing clang-compiled and gcc-compiled c++ may give you grief with exceptions and other things (it would on ARM on 10.x, but maybe not on x86 arches). -- Ian From owner-freebsd-current@freebsd.org Tue Oct 3 17:07:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DE69E42B2D; Tue, 3 Oct 2017 17:07:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7AD81956; Tue, 3 Oct 2017 17:07:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-131-198.dyn.iinet.net.au [106.68.131.198]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v93H7T5K040003 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Oct 2017 10:07:32 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port) To: Ian Lepore , "ports@FreeBSD.org" , freebsd-current References: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> <1507049770.86205.16.camel@freebsd.org> From: Julian Elischer Message-ID: Date: Wed, 4 Oct 2017 01:07:23 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1507049770.86205.16.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 17:07:36 -0000 On 4/10/17 12:56 am, Ian Lepore wrote: > On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote: >> Our 10.4 system is using gcc (for now). >> >> when we compile the devel/binutils port, we get a failure with a >> bunch >> of these errors: >> >> >> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section >> `.rodata' of aarch64.o: defined in discarded section >> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__ >> N_110Stub_tableILi64ELb1EEE]' >> of aarch64.o >> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section >> `.rodata' of aarch64.o: defined in discarded section >> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__ >> N_110Stub_tableILi64ELb0EEE]' >> of aarch64.o >> >> >> I managed to defeat these one before but I forget how. >> >> possibly the answer is to use clang/clang++ for this item but I >> tried >> defining CC and CXX  to clang/clang++ in the Makefile but that >> didn't >> seem to help >> >> there's probably a USE_CLANG option or something that I haven't seen. > We ran into the same thing recently at $work.  The root cause for us > involved having same-named classes in anonymous namespaces in different > compilation units.  The classes made reference to something that was > declared extern "C", bringing into play some rules about how C things > in anon namespaces really refer to the same global C object outside of > any namespace.  Then link-time optimization led to discarding the > object from one compilation unit, and that somehow resulted in > discarding the referenced extern "C" thing completely, even though it > was still referenced from the non-discarded instance of an object from > a different compilation unit.  Phew. > > The same code has no problems with clang on freebsd 11, just with gcc > on 10.3. > > So, for us the fix was a bit heavy-handed: we just renamed one of the > classes involved in the problem so that there were no longer any same- > named classes in anon namespaces in separate compilation units. >  Probably not a good option for you.  A fix involving compile options > might result in not discarding unreferenced segments at all, and with > templated code that might result in huge binaries. > > Mixing clang-compiled and gcc-compiled c++ may give you grief with > exceptions and other things (it would on ARM on 10.x, but maybe not on > x86 arches). > > -- Ian > > thanks the issue comes up in the binutils port which is a dependency of gdb. I don't think we actually need to install the binutils port on our appliance, (and we only install gdb to generate backtraces on debug reports) I just added CC=clang and CXX=clang++ in the makefile that called it and the problem seemed to go away. All i wanted to do is get gdb compiled and I end up with gcc6, llvm and binutils (plus a whole lot more) as a bonus (plus an extra 30 minutes of compile time) From owner-freebsd-current@freebsd.org Tue Oct 3 21:21:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EDFEE24D25 for ; Tue, 3 Oct 2017 21:21:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6801F64611 for ; Tue, 3 Oct 2017 21:21:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0064C2601AB for ; Tue, 3 Oct 2017 23:21:34 +0200 (CEST) To: FreeBSD Current From: Hans Petter Selasky Subject: Booting native 4K SSD disk from FreeBSD ? Message-ID: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> Date: Tue, 3 Oct 2017 23:18:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 21:21:38 -0000 Hi, I accidentially ordered a Sata SSD disk which diskinfo reports a sector-size 4K instead of 512 bytes. Trying to get it to boot under FreeBSD appeared impossible. Then I started looking into the boot0,1,2 and loader and the assumptions they make about 512 byte sector size LBA :-( Anyone has any recommendations or experience about how to use native 4K disks with FreeBSD? --HPS From owner-freebsd-current@freebsd.org Tue Oct 3 21:35:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F96EE2537C for ; Tue, 3 Oct 2017 21:35:46 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 DF7B264F64 for ; Tue, 3 Oct 2017 21:35:45 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from Ticonderoga.HML3.ScaleEngine.net (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 2D3C413108 for ; Tue, 3 Oct 2017 21:35:44 +0000 (UTC) Subject: Re: Booting native 4K SSD disk from FreeBSD ? To: freebsd-current@freebsd.org References: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> From: Allan Jude Message-ID: Date: Tue, 3 Oct 2017 17:36:59 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 21:35:46 -0000 On 10/03/2017 17:18, Hans Petter Selasky wrote: > Hi, > > I accidentially ordered a Sata SSD disk which diskinfo reports a > sector-size 4K instead of 512 bytes. Trying to get it to boot under > FreeBSD appeared impossible. Then I started looking into the boot0,1,2 > and loader and the assumptions they make about 512 byte sector size LBA :-( > > Anyone has any recommendations or experience about how to use native 4K > disks with FreeBSD? > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" It is not possible in legacy/BIOS mode, because the BIOS calls do not let you specify a sector size. However, you SHOULD be able to boot from the 4k device using UEFI. I am trying to debug a problem I am having with this on my new Mac, which has a 4k NVMe disk. -- Allan Jude From owner-freebsd-current@freebsd.org Wed Oct 4 05:16:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E853AE2E4C2 for ; Wed, 4 Oct 2017 05:16:18 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFCEA71BFD for ; Wed, 4 Oct 2017 05:16:18 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0OXA0040097M8U00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Wed, 04 Oct 2017 05:16:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1507094172; bh=v8RIgXgp9M1tvEJs1eZjc9W/+rdrKVSX8Coz6qhSNcQ=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=7lpDVLI3f0ZAqJtr4UDayhfq+YarmJGMyT5ceDoHEXVf1upGM1XzJ8Q1jPCGmFBdH YM1zphppSdnyW6jflH2mC01iIlmq+IZz9M5uj+dZeGgmDclUghhETdXJgSuP8h14z7 DvgOosbOmMm1nsqG58Muwp5agqRmZdT/4bI1H90+4tV1RWnOkfF/Xzu80qL7k0wIGu wpQ8CXCEFPuBjbzwPlivuVyBbGMFIg7XxiLl5fvf4Mwdvb/UTj4l4j4oYoxtEOIVUb UCjTdDmp33u8dwluoE6WHeyZSBnfL7rCibg3IO8X1F0XNA87xZRwq0IATq3HK+v4Om zuRB32JBtErEg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0OXA000C49ARXP00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Wed, 04 Oct 2017 05:16:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-04_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710040076 From: Toomas Soome Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Subject: Re: Booting native 4K SSD disk from FreeBSD ? Date: Wed, 04 Oct 2017 08:16:03 +0300 References: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> To: FreeBSD Current In-reply-to: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> Message-id: X-Mailer: Apple Mail (2.3445.1.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 05:16:19 -0000 > On 4 Oct 2017, at 00:18, Hans Petter Selasky wrote: >=20 > Hi, >=20 > I accidentially ordered a Sata SSD disk which diskinfo reports a = sector-size 4K instead of 512 bytes. Trying to get it to boot under = FreeBSD appeared impossible. Then I started looking into the boot0,1,2 = and loader and the assumptions they make about 512 byte sector size LBA = :-( >=20 > Anyone has any recommendations or experience about how to use native = 4K disks with FreeBSD? >=20 The fastest way right now is via UEFI boot, it should be able to cope = with 4k, but as Allan noted, there may be some corners. The BIOS version is totally out right now, it only is supporting 512B = sectors. I have been working to fix it starting with loader libi386 = biosdisk interface (for loader itself), but due to lack of time it has = been delayed somewhat. The plain loader bits are done, but the +GELI = needs more work (the code has to cope with 512/4k sector and GELI is = only doing 4k logical IO). The hard part is about the boot1 code = (boot1,gptboot etc) and thats due to boot block area size limits (in = existing setups). We are struggling to fit into UFS boot block area, and = freebsd-boot and ESP sizes are also very small, making all this pain in = the =E2=80=A6=20 rgds, toomas From owner-freebsd-current@freebsd.org Wed Oct 4 09:33:27 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A2CCE33F2B for ; Wed, 4 Oct 2017 09:33:27 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-cmomta01.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF467D8E0 for ; Wed, 4 Oct 2017 09:33:26 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([74.134.208.22]) by cmsmtp with ESMTP id zfyYdK3vXzzkYzfyadnLHC; Wed, 04 Oct 2017 09:28:25 +0000 Date: Wed, 04 Oct 2017 09:27:24 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Booting native 4K SSD disk from FreeBSD ? References: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> X-CMAE-Envelope: MS4wfDV+u9JC/LyN8+IEUYQLy8IKhKnHSs10dCxEh347CX0jkJ9kGiZM9invtLvdkibuzxHjXMB3wKpavpkUCRcLiviR/CB554oOPqsqR01p34keWTXTS/wq q4TkSqT6Vij9bDUBtLMmVeV8t231QvWjTtwmJMc/ECP4X4lfsc3wd91m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 09:33:27 -0000 from Allan Jude: > > Anyone has any recommendations or experience about how to use native 4K > > disks with FreeBSD? > > --HPS > It is not possible in legacy/BIOS mode, because the BIOS calls do not > let you specify a sector size. > However, you SHOULD be able to boot from the 4k device using UEFI. > I am trying to debug a problem I am having with this on my new Mac, > which has a 4k NVMe disk. I've been trying to figure how to boot a FreeBSD system with UEFI as opposed to BIOS-style. I read the documentation, but want to boot a partition that might not be the first BSD partition on the hard disk. For instance, some UFS partitions might have a NetBSD installation, a different FreeBSD installation, or no OS installation. I read the man page (uefi) and looked at the files in /boot; have an EFI partition set up with more than enough space. I would also want to be able to boot other UEFI-capable OSes including Linux, NetBSD (if that works), and Haiku when and if possible. Tom From owner-freebsd-current@freebsd.org Wed Oct 4 16:33:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1E56E3D50D for ; Wed, 4 Oct 2017 16:33:02 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 A452768A44 for ; Wed, 4 Oct 2017 16:33:02 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7DAD313AB8 for ; Wed, 4 Oct 2017 16:33:00 +0000 (UTC) Subject: Re: Booting native 4K SSD disk from FreeBSD ? To: freebsd-current@freebsd.org References: <10608d2a-4209-25c1-4117-8568993bfe6a@selasky.org> <20171004093341.C969913E77@mx1.scaleengine.net> From: Allan Jude Message-ID: <0ffdf8a5-b6ad-ab74-9011-c471a96dbf25@freebsd.org> Date: Wed, 4 Oct 2017 12:32:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171004093341.C969913E77@mx1.scaleengine.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 16:33:02 -0000 On 2017-10-04 05:27, Thomas Mueller wrote: > from Allan Jude: > >>> Anyone has any recommendations or experience about how to use native 4K >>> disks with FreeBSD? > >>> --HPS > >> It is not possible in legacy/BIOS mode, because the BIOS calls do not >> let you specify a sector size. > >> However, you SHOULD be able to boot from the 4k device using UEFI. >> I am trying to debug a problem I am having with this on my new Mac, >> which has a 4k NVMe disk. > > I've been trying to figure how to boot a FreeBSD system with UEFI as opposed to BIOS-style. > > I read the documentation, but want to boot a partition that might not be the first BSD partition on the hard disk. > > For instance, some UFS partitions might have a NetBSD installation, a different FreeBSD installation, or no OS installation. > > I read the man page (uefi) and looked at the files in /boot; have an EFI partition set up with more than enough space. > > I would also want to be able to boot other UEFI-capable OSes including Linux, NetBSD (if that works), and Haiku when and if possible. > > Tom > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > In this case, You likely want to install a tool like rEFInd, which will draw a menu of all of the installed OSes and let you pick. I use this in two of my laptops, one dual boots freebsd and windows, and the other OS X and FreeBSD on my macbook pro -- Allan Jude From owner-freebsd-current@freebsd.org Wed Oct 4 18:14:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5676E3F716 for ; Wed, 4 Oct 2017 18:14:03 +0000 (UTC) (envelope-from dpd@dpdtech.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74FDD6C408 for ; Wed, 4 Oct 2017 18:14:03 +0000 (UTC) (envelope-from dpd@dpdtech.com) Received: by mail-io0-x22b.google.com with SMTP id d16so11295127ioj.3 for ; Wed, 04 Oct 2017 11:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=AuAXkQ0mQnMb+CpcLxtsGl71tjvnnUkrErzRBiI9V2o=; b=SJDRJeE9olDsPiF50uuKZA8mo5qZvhjz9l4AoHTNi7mqWx59HVtMsoPUwF0B3wXH6w myDDklVHzbDca2tHSSY7WuHHAv8WEh4vwDdzZB69j4wRkryQmPewFY6arGUHzJAwuCEe VBGcL2OXJl1QBi8OlIF/Fv1YsctkI+56jmP3c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=AuAXkQ0mQnMb+CpcLxtsGl71tjvnnUkrErzRBiI9V2o=; b=snW68LaV3QFFV+KnKehK1z46n9XoTd5PE3usuPC02U3Ek3aDnI03XmC5DG723wPFnr I2pKD0vmYNcYzupgEBUhIAem39c/YpWHrJfXXbqNomd7KDXGGWhp0K3p9c3bAuk4ZEYo IZEIkMaZfiyjmRpm4js1dux0v0FpfpxCYkMvXKlwcJChkmZW3KTLUirhp8XhX6XyumGt BJkNEL2nvF+We+pTKR/l+Czyzhf3Ms+n7nJFsYAtdP6ARcpORqwqJKi6Hx7j/A44JaMu cm52n6sqgnmyf6Y0G0Ky76nmX1OYH7xfUitwBKzI0tF48v/kJIrmT03U4WtvLMCEQqFg t/Pg== X-Gm-Message-State: AMCzsaUo1YkpZS6xCegUVpQjr/R0XViSF6s8j+jCxu1o2r9GYJbUqPaT hac6rtZqvTVwVCxy71X05RKmbN/ASVA= X-Google-Smtp-Source: AOwi7QAzt/of7aZaPaBkK2Nwrog//4ePPvg4YjmIvfKQOrSYRSbEHKZjNtwOTAPxkucqwfpaZas7Kg== X-Received: by 10.107.58.138 with SMTP id h132mr35429703ioa.112.1507140842628; Wed, 04 Oct 2017 11:14:02 -0700 (PDT) Received: from [10.250.1.218] ([12.51.198.59]) by smtp.gmail.com with ESMTPSA id 129sm3244375itk.5.2017.10.04.11.14.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 11:14:01 -0700 (PDT) From: "David P. Discher" Content-Type: multipart/signed; boundary="Apple-Mail=_19547B2F-5316-48D6-8744-D5D56855572E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 12-current, since 323508 / Sept 13 - smartctl / smartmontools - unable to query drives Message-Id: Date: Wed, 4 Oct 2017 11:14:00 -0700 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:14:03 -0000 --Apple-Mail=_19547B2F-5316-48D6-8744-D5D56855572E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seeing an odd behavior - even with r324216 as of about Oct 2nd, smartctl = can no longer query any disks Always getting: > sudo smartctl -x /dev/ada0 Password: smartctl 6.5 2016-05-07 r4318 [FreeBSD 12.0-CURRENT amd64] (local = build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, = www.smartmontools.org /dev/ada0: Unable to detect device type Please specify device type with the -d option. Use smartctl -h to get a usage summary Even with specifying the type, I can=E2=80=99t query the drives. I=E2=80=99= m trying to nail down the commit now, I think its between r320087 and = r323508. Anyone have any pointers ? Smartmontools hasn=E2=80=99t changed since = Feb, so by all indications, this is a regression in = FreeBSD-current/-head. Thanks ! -- David P. Discher https://davidpdischer.com/ --Apple-Mail=_19547B2F-5316-48D6-8744-D5D56855572E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZ1STpAAoJEE0c/2p89k7lo4EH/ipG8ZqFE2F2i3Pa597U3k/B Ef08SnuG+ZTbt3n7AttQqhSVgZNUHeM8xK4pHe2UTTATFrFGQxKSIchnXE/2OTmE TMR+tIBKlTlcHnE5h0WcrIDCR+Qn7YoT4fRFIX/koYnhmZKumpWJcDjQZuxiU18t C0Q+ASxUIwV2SCqcy6tZLvIpjkBrRLY10F1aFnMrpFa7ucWZl9wS/eyO6dfjJ4Pl n7mg9zc0GRnnh4VR7lML/VEcl231BaAos9y9zV7Rg2lXhghe+upqWK3089S1duOF 2qh6HgiIkv17y+IYwxcuif6ltBszNH7M6dzQ3O2pJ27QKE01/QtIZtjudQ5R4+I= =Mqyj -----END PGP SIGNATURE----- --Apple-Mail=_19547B2F-5316-48D6-8744-D5D56855572E-- From owner-freebsd-current@freebsd.org Wed Oct 4 18:42:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3619BE3FF0C for ; Wed, 4 Oct 2017 18:42:46 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:191:217b::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 052036D2AC for ; Wed, 4 Oct 2017 18:42:45 +0000 (UTC) (envelope-from herbert@gojira.at) Received: by mail.bsd4all.net (Postfix, from userid 1001) id AE46E65F2; Wed, 4 Oct 2017 20:42:43 +0200 (CEST) Date: Wed, 4 Oct 2017 20:42:43 +0200 From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: 12-current, since 323508 / Sept 13 - smartctl / smartmontools - unable to query drives Message-ID: <20171004184243.GA36804@mail.bsd4all.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:42:46 -0000 On Wed, Oct 04, 2017 at 11:14:00AM -0700, David P. Discher wrote: > Seeing an odd behavior - even with r324216 as of about Oct 2nd, smartctl can no longer query any disks > > Always getting: > > > sudo smartctl -x /dev/ada0 > Password: > smartctl 6.5 2016-05-07 r4318 [FreeBSD 12.0-CURRENT amd64] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org > > /dev/ada0: Unable to detect device type > Please specify device type with the -d option. > > Use smartctl -h to get a usage summary > > Even with specifying the type, I can’t query the drives. I’m trying to nail down the commit now, I think its between r320087 and r323508. > > Anyone have any pointers ? Smartmontools hasn’t changed since Feb, so by all indications, this is a regression in FreeBSD-current/-head. > > Thanks ! Rebuild smartmontools! -- Herbert From owner-freebsd-current@freebsd.org Wed Oct 4 18:43:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F508E3FFF0 for ; Wed, 4 Oct 2017 18:43:50 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 4E7D76D400 for ; Wed, 4 Oct 2017 18:43:50 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id 47so21027825qts.10 for ; Wed, 04 Oct 2017 11:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=htMRDSy0f5nydRuSozF/Wfj0JaZ9H5bGDCrn9vv+uAs=; b=vUZ1azeyHDUY4Go7tpuquN3iIUpWOZNPXstv3kFJ1ldMI8Pt/AVZvNBhHqgqTb3cQR VYnEQzEkCBN//UbwqBWeWo9BHraEnPUcKo521ykDDiFknzitLA9WbutoySwW5zfYe134 pQPd8DQT+W5lz6EkyLh6S7i7HOxPgy2VkGWgCnuhk3/92WmsoXGHGn6qdFB6NfkL6HKj Kvui3tku7yY7jUTF9X+gQ9QrK7nVScutnc8zjsbN6gIcdbCIMabl32CQTdmu+lbpXIsZ LdIA8UBZQgXxclXa8rzM5kDSE9TvOiAc2wZW3Qa3isSpDFZkbwQb8Ci31ADkhC7nVPBy nsjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=htMRDSy0f5nydRuSozF/Wfj0JaZ9H5bGDCrn9vv+uAs=; b=pOlZhTXigt0iXcKzcFjKC83wjrk2O84pQDMkIesdJgKo0tyTyWBVZ1QCqsrCzsgnPm 481e3kXN+LpVFOp6UTAqZjyL2cbRp20/x6ipP4E6PkSfaVCrRVuJWoVX6ZKQ9htB57fA CCH9o/o6B6YD/uZRsKmV6z48wUmloEF57QLo0KDfDKXOrUs8WrxuetG9FuoDHAsQVuAZ TqgvwlDThp95JJmdoefwvxO/qz/uteAmkGNo7aMJnNQKcMb0tJ+kUs5k66nDpw+b6wKk Hclf3QSOq8Cgmzh+L/xBPObVFPFbMPFm5QEaDJFI44BrLpXnUg/2e5Zu5JG12x59KbI1 xMzA== X-Gm-Message-State: AMCzsaXWI5ZvFqcENiYLmTsX7FspPGM8hNVKzObLcqI+o07R6lnx8wa/ lsIj9o1IkZ7rgRcq/mC5kwD4lNNhcFqgxqy9PZc= X-Google-Smtp-Source: AOwi7QBwksJHUWxoQv36q+oNFajDXzBNOW+gvFA7qUbgEKwi9W8X1SHvPys7vh+MU/oz+D91vO/QOOxNAywqwRmZsYk= X-Received: by 10.37.187.137 with SMTP id y9mr4760776ybg.302.1507142629115; Wed, 04 Oct 2017 11:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.219.132 with HTTP; Wed, 4 Oct 2017 11:43:48 -0700 (PDT) In-Reply-To: References: From: Ultima Date: Wed, 4 Oct 2017 11:43:48 -0700 Message-ID: Subject: Re: 12-current, since 323508 / Sept 13 - smartctl / smartmontools - unable to query drives To: "David P. Discher" Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:43:50 -0000 Just recently tested smartctl (a few days ago) r324135 and I found that the auto detection seems to be broken but manually selecting the device type works. Are you positive you tested every device type? I was a bit surprised to find that atacam works for my onboard controller and the HBA only works with sat,auto and scsi On Wed, Oct 4, 2017 at 11:14 AM, David P. Discher wrote: > Seeing an odd behavior - even with r324216 as of about Oct 2nd, smartctl > can no longer query any disks > > Always getting: > > > sudo smartctl -x /dev/ada0 > Password: > smartctl 6.5 2016-05-07 r4318 [FreeBSD 12.0-CURRENT amd64] (local > build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, > www.smartmontools.org > > /dev/ada0: Unable to detect device type > Please specify device type with the -d option. > > Use smartctl -h to get a usage summary > > Even with specifying the type, I can=E2=80=99t query the drives. I=E2=80= =99m trying to > nail down the commit now, I think its between r320087 and r323508. > > Anyone have any pointers ? Smartmontools hasn=E2=80=99t changed since Fe= b, so by > all indications, this is a regression in FreeBSD-current/-head. > > Thanks ! > > -- > David P. Discher > https://davidpdischer.com/ > > > From owner-freebsd-current@freebsd.org Wed Oct 4 23:42:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 231FAE23BB5 for ; Wed, 4 Oct 2017 23:42:11 +0000 (UTC) (envelope-from dpd@dpdtech.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 D59CF76CDC for ; Wed, 4 Oct 2017 23:42:10 +0000 (UTC) (envelope-from dpd@dpdtech.com) Received: by mail-oi0-x232.google.com with SMTP id q4so4586888oic.7 for ; Wed, 04 Oct 2017 16:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EKE8k7ZeIBsB482XCEhOHDoN28qydmqVfrzj636bm6g=; b=VVr+pRQtDMkWHXUqwa1dVgX13m/769EbbvRrtu9mW+iSWwMAlVqRyesu3gcXogjhnA YZK9HbQeuJUKTYa1DHEXKRAyrlS7HzNCgz46bRGcGQjfutQggsZg3VxY5gAcAkctwmh8 Rct8lCGcldjVOBHm3V9WUgyledQRt+fib3EgM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EKE8k7ZeIBsB482XCEhOHDoN28qydmqVfrzj636bm6g=; b=MOzBLRVy+HPDE6nM3GtUidWzS+yv2BYBbqQX4ALHw/a4Pw8CCz12WUhQGAdj5VX8HJ Zp+xPRaTHqRCZq92hVIeYa4BUEWRz1g0vMLjAqJPXwyxeUcZoy8FqSweEthZV+kUNPLd C8gsbxrXXs3l1F5KJVojoOjUwNUBa3gNYc4+1yDjbu5sP2y/b/QYntIh8nxtdiwb4xEt OWyjl5fI+grrQsxzVxDvrW7vWqglEZge4CqyDeIabfHpo0/okd+y8Nc64iIokXPib7RE 5Vh4fK2EXvvL/qUwClATCREA9MVk/aVn4bsgkfanNEpodBzmZTS5vvzH8aCjsI4A6itD SzLw== X-Gm-Message-State: AMCzsaV5F4mSld7uQjrC0rqp31DXV8Yua40Ebr9SKZ+VKCoZN7EL0lDa 8xxEMEjY46AE8tMjrao6fFfF9dStyEU= X-Google-Smtp-Source: AOwi7QBFY1x6+wNx4Z/0m+a+ZgNKDb61OkokKE51Vhoi0tCbt1bXXYOdSE6V+moTmyXqAfnh2eBwbA== X-Received: by 10.157.4.202 with SMTP id 68mr13046353otm.140.1507160530004; Wed, 04 Oct 2017 16:42:10 -0700 (PDT) Received: from [10.250.1.218] ([12.51.198.59]) by smtp.gmail.com with ESMTPSA id f187sm7860069oig.24.2017.10.04.16.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 16:42:09 -0700 (PDT) From: "David P. Discher" Message-Id: <0B72820C-3D56-4552-80A6-FF8309CF24B3@dpdtech.com> Content-Type: multipart/signed; boundary="Apple-Mail=_515029C9-0DDA-46B7-A8CD-DE715F429E4A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 12-current, since 323508 / Sept 13 - smartctl / smartmontools - unable to query drives Date: Wed, 4 Oct 2017 16:42:07 -0700 In-Reply-To: <20171004184243.GA36804@mail.bsd4all.net> Cc: freebsd-current@freebsd.org To: "Herbert J. Skuhra" References: <20171004184243.GA36804@mail.bsd4all.net> X-Mailer: Apple Mail (2.3273) X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 23:42:11 -0000 --Apple-Mail=_515029C9-0DDA-46B7-A8CD-DE715F429E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 4, 2017, at 11:42 AM, Herbert J. Skuhra = wrote: >=20 > On Wed, Oct 04, 2017 at 11:14:00AM -0700, David P. Discher wrote: >> Seeing an odd behavior - even with r324216 as of about Oct 2nd, = smartctl can no longer query any disks >>=20 >> Anyone have any pointers ? Smartmontools hasn=E2=80=99t changed = since Feb, so by all indications, this is a regression in = FreeBSD-current/-head. >>=20 >> Thanks ! >=20 > Rebuild smartmontools! Doh ! Thanks - this was indeed the problem. I=E2=80=99ll need to be more careful with head. -- David P. Discher https://davidpdischer.com/ --Apple-Mail=_515029C9-0DDA-46B7-A8CD-DE715F429E4A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZ1XHQAAoJEE0c/2p89k7lRUIIAJsMtq03frttHfTXJzWrNBRW PmhJo0PJYLkhlwU9X+oxAikleHGRjwAbnH7pC08QcK9dQvLc98537BuWYUSmEpSc FY3GU1iqntew1OxN3rwEoQaCXGKqOuuaVg8rzJ8OAPx1vCAiJWBYnb0Wf+6pfcAz Sv1md9i+jYse70UaznPtIg5gzN8ntUxcdxN94XNqPyKnoCe6HAZNkyBDtTP+ILZC 7gqk8v9GfzJPKn9Wp6gKEBYt8TwPCdxkGYGBDictYK5FHhJVtkFo6P1zvL1iQKtP XVK72mymGXR4XBlrsGt5g17OHOrXQ/GIMtcX5LbBNXzIrfvlDDobiuUu17M9Xs8= =JAp1 -----END PGP SIGNATURE----- --Apple-Mail=_515029C9-0DDA-46B7-A8CD-DE715F429E4A-- From owner-freebsd-current@freebsd.org Thu Oct 5 15:17:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AD24E3B071; Thu, 5 Oct 2017 15:17:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5840F75897; Thu, 5 Oct 2017 15:17:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 45B0C10F11; Thu, 5 Oct 2017 15:17:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 5 Oct 2017 15:17:15 +0000 From: Glen Barber To: freebsd-doc@FreeBSD.org Cc: freebsd-current@FreeBSD.org, FreeBSD Documentation Engineering Team , FreeBSD Release Engineering Team Subject: HEADS-UP: release-releated documentation moving from base to doc repository Message-ID: <20171005151715.GB49395@FreeBSD.org> Reply-To: gjb@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 15:17:18 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have expressed my intent to move the release-related documents from the src tree to the doc tree in the past. This has been met with some resistance, but I think this change is far overdue at this point. The primary motivation behind this change is that if there is an error in release-related documentation that goes unnoticed until the release announcement is sent, we are effectively stuck with the erroneous information in the release notes (although we can document the error in the errata.html page), as once the release is tagged in Subversion, the sources that generate the relnotes.html, readme.html, etc., cannot be modified. Moving the sources from the base repository to the doc repository (which does not have an explicit "freeze") allows us to change incorrect entries, add missing entries, etc. post-release, as needed. I am currently re-testing and triple-checking the changes to pull the relevant files into the doc repository in preparation to commit the changes, which I expect to have in the tree within the next few hours if all goes well. At latest, it should be committed by tomorrow. At present, I am undecided if I will make this change retroactive to stable branches. I do not expect any doc build breakage, but assume I am looking into anything that breaks as a result. Please bear with me if things do explode. Thanks. Glen --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnWTPsACgkQuWzd6q+L XtArsw/+M6/BAZphwK79bF8yoyk3ePogG/pSuR4LUOSJWpF4H2ZFaqP+oz74Gw6Y dSLk/3nL22aCbxSAarestZGMP91xsEwhjW5jTSg5Vyqvm0hRRD87HiIDOK3/95jc TnhP52pNEpEtS11aXyDmmUtcfCtRZWZ4TzZJc320hA/pJYrlnZlBl7iOKSC3SEOO z+BNWSafhUN1N/pMSi06OOunmH4obhKwNRZoju8MVbra8F3VZVOYUWkEOD8OesXT JvfoUNsApB4BQJ5qwwBfzgTzGPswQM5z2Zo+KSddSKzkhIKqy4k57H8Ne4o6+xOr UMEQE8T+l0mkMrMSsG+gZlmJrWPhiIQtBQkqeuL2r/Z/s4zpT1jFbEllrbYTA8OA o8hWgDNfpEnioK0IE0TWuOWeCGoOEQbqwf95PDV/ToBNjG7RiMEpvIJRftNTM1Fw wHCzP9NK2JRFuMUBtZTC3oxnxQsgTXuWcRHEsHYL1MDUJsew3NKL5QrcykxGH+FQ tBuIBC7ECIWVNzwc4rpBSk0+dVqRwn787bPa7ZF1akUOxHQsp0S5Wb08tkbJnBKK EcpqGFK0FB2C/s/IxQNExpKX0RxeKodAMU9DYjWVEDHWiBv7McjrS7BCeleh+QJN BHSRBAny/jhvHTzlZ9pOhy7OCJ6V6hkqmY4JjWQ0loz3jor6zK8= =VUtf -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-current@freebsd.org Thu Oct 5 18:59:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AE83E3FB1C for ; Thu, 5 Oct 2017 18:59:07 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E641581E5D for ; Thu, 5 Oct 2017 18:59:06 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id f4so4015976wme.0 for ; Thu, 05 Oct 2017 11:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r4ULis5AFnuTEPq6Xc+z8QLu290mxemNUAHF/mKrHBM=; b=ZZ/uAxDaipfP+KxGPIl5quCeqxFcbIOeFdlfe2j3c0W5IXvj1Co5jlGyfswCOxluiJ M5ngbjW059h+gdnM057eW1u2LU6koIZCNLg7nt07bSYHyqZ8UMWCppkiLMPVUIsM3mpt jazmdFgdQtKz/ohdF5VLQImpp2r1WKz5KoCTTx++6r+ayDHD4ZxjNbO3punGkmT2LAnR DVHHNMVuE/IXNmd2VdpaybF4vYpuecsX3NNAARBzlGRIm9EX9AjLhJupxOXxcGSp5pGb HzN79+VaGmQbOOtgqRE/N2Wa+CfmfxnCjJqT+1yadkLb5sRRozVaMAlIv6wo57u+f356 w0Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r4ULis5AFnuTEPq6Xc+z8QLu290mxemNUAHF/mKrHBM=; b=Ol2pSC/L45/RvpKJlG6Vx4DFn6/kPBGFnORl2PGnZjTsXkOMa0raGKDCVbbg7Srf7a zsqJ73Yup/Tp3XNK9EasvP2J29I1xPzO+SYYAu7ghyIbAeYaU2xGji6ljWVmfIGRbdVA Fd2neR3PQ3d0N+rLRvgTdVrINsDRQzfPXEcSG1Wee2SslgffSpbpuCTAenpocjdKvucQ KJCvcErkhC7qmIlMhualJF2sWlwtt9DUhgzwz4MRLJi4v5rM8OZCBki0IwruXtaUdII+ eEmMVedmhQM3bef/HbxbjZyG5ZJ6DmGylgVBFNzTdGsnvxy6bfQY9KTy7yvlbY4kvPS4 oO0g== X-Gm-Message-State: AMCzsaXk0SoxvHwm43aP+mCmFmtx/gabj9NBLfX5xVL1mAA7F8kn1CRD SORnHHQO8XsZt59kljRPUZLnVtzOHPDGiSP3FPtsv22l X-Google-Smtp-Source: AOwi7QDVMGAFqyYofZQsfcVFKmJNhYzm9thI6ACgM4b/3+/2ys4DZBA9Qd++x62OqwHgnPtjZ0j3NYrcuPPGg2Dy5Mc= X-Received: by 10.28.29.68 with SMTP id d65mr74326wmd.93.1507229944125; Thu, 05 Oct 2017 11:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.196 with HTTP; Thu, 5 Oct 2017 11:59:03 -0700 (PDT) From: David Goldblatt Date: Thu, 5 Oct 2017 11:59:03 -0700 Message-ID: Subject: C++ in jemalloc To: freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 05 Oct 2017 20:38:38 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 18:59:07 -0000 Hi all, The jemalloc developers have wanted to start using C++ for a while, to enable some targeted refactorings of code we have trouble maintaining due to brittleness or complexity (e.g. moving thousand line macro definitions to templates, changing the build->extract symbols->rebuild mangling scheme for internal symbols to one using C++ namespaces). We'd been holding off because we thought that FreeBSD base all had to compile on GCC 4.2, in order to support some esoteric architectures[1]. The other day though, I noticed that there is some C++ shipping with FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING document that C++11 is a minimum for FreeBSD 11). This, combined with the fact that ports now points to a modern gcc, makes me think we were incorrect, and can turn on C++ without breaking FreeBSD builds. Am I right? Will anything break if jemalloc needs a C++ compiler to build? We will of course not use exceptions, RTTI, global constructors, the C++ stdlib, or anything else that might affect C source or link compatibility. Thanks, David (on behalf of the jemalloc developers [1] That being said, we don't compile or test on those architectures, and so probably don't work there in the first place if I'm being honest. But we'd also like to avoid making that a permanent state of affairs that can't be changed. From owner-freebsd-current@freebsd.org Thu Oct 5 21:01:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01F77E42AFE for ; Thu, 5 Oct 2017 21:01:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 C6723223A for ; Thu, 5 Oct 2017 21:01:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id z187so14542351ioz.12 for ; Thu, 05 Oct 2017 14:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=88U4oWEzxDuq91RKoFq99a6jE/Sd9Qpwql5YxWAbU/8=; b=VxA2S8vYW0U8tQBra3W7fw0FtVVIrLfVxbGDFWn4oUT9hA3VigwqISaZgwpeKGbhIm MlXfQOTJWZZA4sUZbPjBXLVlq+q0840rHmppqxntAiogecVNbpAU3fjfeJ1wjvQhim96 6xSH+tIGQbb776j6hy2+6P5CDoEhSnc1d87/C/T4wKWEtZz//zpxoTF7M1rrKHhoFdlr 7zS72qWALy6544NQha7TZ2iLtQV/Tf9k2XhL2L8bHlQC8l8o+D/y6XL+588kpmPNF8hr hwiAVG3+0MBV9TmqJEyC9ytKBLQ7sBvqH6RFfx1GwFYuNfJVQ4rCbOF3aDxOhgHsvIe+ HfHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=88U4oWEzxDuq91RKoFq99a6jE/Sd9Qpwql5YxWAbU/8=; b=rZSourn8x/XIFZ4kTLUeFF08lsToTcL+57JJFZPElZE2ZZj9/WJFXgc3sYndRGhdA4 Vt9QCG5VKraXHcfkwyLXy1ZNSt/dQb8qLJrGeBmhh73f9t03xn65l9Pv+spf7T1ekZJe YO9mEm/eHEESw53hXbAPYVPWgDJgxAqZH/7xTahJGqiOwtd5QZtcUEbMGGwkKTa8XpRN OFBxooTMktkUozm7nvgajJ6LkgdVnZEadPUor8RG3vwp36HoGUwhdc5+yYdjP5DRrIK6 ILOC0UjG02liv8QBR72cfc2asdq48YehJT6mn15g9Vk2bBjaZ4yvFlSM4EUc5qG287HJ 0ObQ== X-Gm-Message-State: AMCzsaU8YBMEls90IVXbgtgUNcV4RwVg4g4wS/uc3GKG7gJmnYDLfEjd nGACEGzraaoTBQN89Qz1irvsKqkOSTBH6HMpqsIJzg== X-Google-Smtp-Source: AOwi7QD63O4e/OJnNSQYiofJYHddMPTGSfHDr4hV5taA86vunYts7UfJ7V0j5H4Z+L83MeDQOyzk2fhZhGCfJysQ6Hs= X-Received: by 10.107.133.85 with SMTP id h82mr7735323iod.208.1507237284827; Thu, 05 Oct 2017 14:01:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 14:01:24 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] In-Reply-To: References: From: Warner Losh Date: Thu, 5 Oct 2017 14:01:24 -0700 X-Google-Sender-Auth: _n0JbtinUuoPG27KjDfV_wKB910 Message-ID: Subject: Re: C++ in jemalloc To: David Goldblatt Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:01:26 -0000 On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. > For FreeBSD 10 and earlier, this would likely break all architectures that aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by clang, but not super well. For FreeBSD 12, we're getting close for everything except sparc64 (whose fate has not yet been finally decided). So for the popular architectures, this arrangement might work. For building with external toolchains, it might also work. Some of the less popular architectures may be a problem. Does that help? It isn't completely cut and dried, but it should be helpful for you making a decision. Warner From owner-freebsd-current@freebsd.org Thu Oct 5 21:21:22 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EA30E42E5F for ; Thu, 5 Oct 2017 21:21:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 16B892C08 for ; Thu, 5 Oct 2017 21:21:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id p184so18106084lfe.12 for ; Thu, 05 Oct 2017 14:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UiEs2zaoOc2GfOL0OWQjQA1/iU3svSf69E7LSydAH98=; b=Txc8Q6V/wo/GFYHgFLJILPR9cm0QbFssQoipXDIgaRay/tecPe8Vc5zE+Ad+e5s44h 3QYYLUh6dno/CDtEuPCp7LRlWGt4TGQVkRFI4GRCYkS2OHHgtXxVyA2tKchRCi71PYta 9OsZH7yHDoDwHbinPcZTrH1aoJl27VSUMA6DJEiqM34OJ6an+OzPCfmBj5sMpiECO2FH Zm/YB7I8VVBAqGKAHrJtEtb4HJNtEbqW29/FymiTLCKNB3mf5j1slJGF7lRvtI/VXpEh XxIJZHUaLT8COeql7PPbqPtx0p1eID9paq1B/gluQtM/Lyh0wCvq7w1t4T6yxTYqmjuV 3HGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UiEs2zaoOc2GfOL0OWQjQA1/iU3svSf69E7LSydAH98=; b=AnTNRFN9AULX4zCPuvAjwxPM2I9d5Ar0vyK4eJkpB5Nxvd8lc8GHnymoZAa/EqZty3 43e+taJMIQvUzRxypQ5Dn29EwvLHdknlntm7DxM19a4ZTfn5BLh0Syb6kW4pAwo8kv/X M7Pf5dhGSIZ+6ayISV5OxxYvkCkhNSkHkcHhSBsHT/LlgL/5ulouj/S8jPIGBEccuQaM crw9vrJAanozrkz9MEcaVF4S/t2ssAK7GDaIvHi/Q+T2c0fjNVD+jkIs5m93gv3e3cyD sgkOkLT9sRy2EecDm9DJoRwElP7RQf/ZZgCz9GgrjkY9qWxS5GZaiCiCGNxweGOiiXVe tYhg== X-Gm-Message-State: AMCzsaUz2HAY1CHYfCkc9mxtIwJrZIZhWCF5cG0QIQK++piGAB9xeoFc 7PFRm66Dg9U7cNp8msNh31+L3z+pZG64RGimZU4= X-Google-Smtp-Source: AOwi7QCPibC48C9nFgePM/pDqM6n8Vbtm3wlVKcf/SUmR0Hn8JJbTqRQJMWmwIMFYF5IjOLZ6ZW693MK5oYcK9Yd59U= X-Received: by 10.25.23.38 with SMTP id n38mr18343lfi.104.1507238478053; Thu, 05 Oct 2017 14:21:18 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.7.153 with HTTP; Thu, 5 Oct 2017 14:21:17 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Thu, 5 Oct 2017 15:21:17 -0600 X-Google-Sender-Auth: WvbIelEw-wpz-hY8_2FEYZ0-DyI Message-ID: Subject: Re: C++ in jemalloc To: Warner Losh Cc: David Goldblatt , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:21:22 -0000 On Thu, Oct 5, 2017 at 3:01 PM, Warner Losh wrote: > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > wrote: > >> Hi all, >> >> The jemalloc developers have wanted to start using C++ for a while, to >> enable some targeted refactorings of code we have trouble maintaining due >> to brittleness or complexity (e.g. moving thousand line macro definitions >> to templates, changing the build->extract symbols->rebuild mangling scheme >> for internal symbols to one using C++ namespaces). We'd been holding off >> because we thought that FreeBSD base all had to compile on GCC 4.2, in >> order to support some esoteric architectures[1]. >> >> The other day though, I noticed that there is some C++ shipping with >> FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING >> document that C++11 is a minimum for FreeBSD 11). This, combined with the >> fact that ports now points to a modern gcc, makes me think we were >> incorrect, and can turn on C++ without breaking FreeBSD builds. >> >> Am I right? Will anything break if jemalloc needs a C++ compiler to build? >> We will of course not use exceptions, RTTI, global constructors, the C++ >> stdlib, or anything else that might affect C source or link compatibility. >> >> Thanks, >> David (on behalf of the jemalloc developers >> >> [1] That being said, we don't compile or test on those architectures, and >> so probably don't work there in the first place if I'm being honest. But >> we'd also like to avoid making that a permanent state of affairs that can't >> be changed. >> > > For FreeBSD 10 and earlier, this would likely break all architectures that > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by clang, > but not super well. For FreeBSD 12, we're getting close for everything > except sparc64 (whose fate has not yet been finally decided). > > So for the popular architectures, this arrangement might work. For building > with external toolchains, it might also work. Some of the less popular > architectures may be a problem. > > Does that help? It isn't completely cut and dried, but it should be helpful > for you making a decision. > > Warner To be clear, Warner is talking about C++11 code in jemalloc. C++98 will work fine on all architectures, and I think most of C++03 will too. dtc(1) is allowed to use C++11 because it only builds on architectures that support it. -Alan From owner-freebsd-current@freebsd.org Thu Oct 5 21:24:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CE89E43091 for ; Thu, 5 Oct 2017 21:24:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 80B6A3034 for ; Thu, 5 Oct 2017 21:24:41 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 99bc1cf9-aa13-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 99bc1cf9-aa13-11e7-a937-4f970e858fdb; Thu, 05 Oct 2017 21:24:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v95LOWl4004399; Thu, 5 Oct 2017 15:24:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507238672.86205.250.camel@freebsd.org> Subject: Re: C++ in jemalloc From: Ian Lepore To: Warner Losh , David Goldblatt Cc: FreeBSD Current Date: Thu, 05 Oct 2017 15:24:32 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:24:41 -0000 On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > wrote: > > > > >  Hi all, > > > > The jemalloc developers have wanted to start using C++ for a while, to > > enable some targeted refactorings of code we have trouble maintaining due > > to brittleness or complexity (e.g. moving thousand line macro definitions > > to templates, changing the build->extract symbols->rebuild mangling scheme > > for internal symbols to one using C++ namespaces). We'd been holding off > > because we thought that FreeBSD base all had to compile on GCC 4.2, in > > order to support some esoteric architectures[1]. > > > > The other day though, I noticed that there is some C++ shipping with > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > > document that C++11 is a minimum for FreeBSD 11). This, combined with the > > fact that ports now points to a modern gcc, makes me think we were > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > > We will of course not use exceptions, RTTI, global constructors, the C++ > > stdlib, or anything else that might affect C source or link compatibility. > > > > Thanks, > > David (on behalf of the jemalloc developers > > > > [1] That being said, we don't compile or test on those architectures, and > > so probably don't work there in the first place if I'm being honest. But > > we'd also like to avoid making that a permanent state of affairs that can't > > be changed. > > > For FreeBSD 10 and earlier, this would likely break all architectures that > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by clang, > but not super well. For FreeBSD 12, we're getting close for everything > except sparc64 (whose fate has not yet been finally decided). > > So for the popular architectures, this arrangement might work. For building > with external toolchains, it might also work. Some of the less popular > architectures may be a problem. > > Does that help? It isn't completely cut and dried, but it should be helpful > for you making a decision. > > Warner Wait a sec... we've been compiling C++ code with gcc 4.2 since like 2006.  What am I missing here that keeps this answer from being a simple "go for it"? Just stay away from C++11 features and gcc 4.2 should work fine.  (DTC may require C++11, but that was likely the author's choice given that there was no requirement for it to work on pre-clang versions of freebsd). -- Ian From owner-freebsd-current@freebsd.org Thu Oct 5 21:33:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA93EE43300 for ; Thu, 5 Oct 2017 21:33:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ED7D34A8 for ; Thu, 5 Oct 2017 21:33:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id i38so2227424iod.2 for ; Thu, 05 Oct 2017 14:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j8GhWZH5xrIcPpV7Ro+IZLQXAA6/Bdvzh1iZopHfYCg=; b=g/NLmZvaotwbLRyOXIKup55KwkJmvVuZx0o6FExpZC0fqRY09KttAcuBzPff+IMHDJ 1l6iNXjJKTMiJwkOV8Xy4ICZU0xLEIvSM/z75qF///84DjjvYS5UulweCOOZfkyZ3LC5 bu/xVPY6DX4C8CcGtoloX7A/WcnPuFLXSExroDs58b0tfL68Ab5CD4fsA42Iq5d2FtCJ s9WW5DyPZnN/XZqMapLkncy/MgCFDyc2+XEFusak5k2s0z7EWBuub2TmJi4F8sueJM7R qgVcWj+3jgD0JoJVWiHS4sbtLnXvqzH4H7bm9xFpKLIGfty6kl+hM49cxPwk8yPO5cY0 w7YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j8GhWZH5xrIcPpV7Ro+IZLQXAA6/Bdvzh1iZopHfYCg=; b=frEqZQCYbZi174xV+0/Bm61Bquw+pmx2to39gtipOhP856rJRZByoZt5oIcQ10yW5F IPC6uhiCWT5s9WxsssU0NKdBrfcyL9riGPMueQHkrlhTt7OT8IIFwn7vN+jDol5CYTlr PM+bH0WKUuEE1sQBUbzwT68uXHABBa8i1Wq2JlUUJ6HIo6/+INIlPKPH7KWHEGuEO1kk zeQBn6hCVosX5aT5Kuc/tZ4VOhelIKio0JpcwDc8Nq2W0zMDzz7bn6xIw6ea4sBzdelA 2oDQA+KjWY+cB7ue4JeCq+LhoM69hgsVbx5lCteMClLlTISHBVZxzovY8xSz+fFd+UVy xLEg== X-Gm-Message-State: AMCzsaWBS4miIOKPWsBsE8Slqqm+sDu/EIFuymv4rRr+tPFUh0wAPWcH ncfUAE1bzsgfMA25ZavnP1HPxagrnWSCyMi4Q/EhTQ== X-Google-Smtp-Source: AOwi7QD2LqRMjwmVNZwKKrJSeTtl/2IrkgJYEEmOlwbv5KpErae7QJdJhgKZgtd6azV2XJJWZGc8/fzgY/fFhOPlgPU= X-Received: by 10.107.135.147 with SMTP id r19mr91177ioi.26.1507239205702; Thu, 05 Oct 2017 14:33:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 14:33:25 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <1507238672.86205.250.camel@freebsd.org> References: <1507238672.86205.250.camel@freebsd.org> From: Warner Losh Date: Thu, 5 Oct 2017 14:33:25 -0700 X-Google-Sender-Auth: WX6pyNxzc8ImPqTwIRKLGSPCYJM Message-ID: Subject: Re: C++ in jemalloc To: Ian Lepore Cc: David Goldblatt , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:33:26 -0000 On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > > wrote: > > > > > > > > Hi all, > > > > > > The jemalloc developers have wanted to start using C++ for a while, to > > > enable some targeted refactorings of code we have trouble maintaining > due > > > to brittleness or complexity (e.g. moving thousand line macro > definitions > > > to templates, changing the build->extract symbols->rebuild mangling > scheme > > > for internal symbols to one using C++ namespaces). We'd been holding > off > > > because we thought that FreeBSD base all had to compile on GCC 4.2, in > > > order to support some esoteric architectures[1]. > > > > > > The other day though, I noticed that there is some C++ shipping with > > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the > HACKING > > > document that C++11 is a minimum for FreeBSD 11). This, combined with > the > > > fact that ports now points to a modern gcc, makes me think we were > > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > > > Am I right? Will anything break if jemalloc needs a C++ compiler to > build? > > > We will of course not use exceptions, RTTI, global constructors, the > C++ > > > stdlib, or anything else that might affect C source or link > compatibility. > > > > > > Thanks, > > > David (on behalf of the jemalloc developers > > > > > > [1] That being said, we don't compile or test on those architectures, > and > > > so probably don't work there in the first place if I'm being honest. > But > > > we'd also like to avoid making that a permanent state of affairs that > can't > > > be changed. > > > > > For FreeBSD 10 and earlier, this would likely break all architectures > that > > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by > clang, > > but not super well. For FreeBSD 12, we're getting close for everything > > except sparc64 (whose fate has not yet been finally decided). > > > > So for the popular architectures, this arrangement might work. For > building > > with external toolchains, it might also work. Some of the less popular > > architectures may be a problem. > > > > Does that help? It isn't completely cut and dried, but it should be > helpful > > for you making a decision. > > > > Warner > > Wait a sec... we've been compiling C++ code with gcc 4.2 since like > 2006. What am I missing here that keeps this answer from being a > simple "go for it"? > > Just stay away from C++11 features and gcc 4.2 should work fine. (DTC > may require C++11, but that was likely the author's choice given that > there was no requirement for it to work on pre-clang versions of > freebsd). > It's the ubiquity of C++11 is why I didn't just say "Go for it". Warner From owner-freebsd-current@freebsd.org Thu Oct 5 23:00:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E7D4E449EF for ; Thu, 5 Oct 2017 23:00:26 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFF5765069; Thu, 5 Oct 2017 23:00:25 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id t69so4593688wmt.2; Thu, 05 Oct 2017 16:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m3ctSadbE0w1fwgAlbODWFAg6/Dlpm1WeYBp6eN3uX8=; b=p9gEXSLNthjB6NxqyCdo3FXBkqKr/7qCoTIEOQzo+3nstAaN6GxQzdXM1Q8fnsOIZK 5FcdljIGiSLxwdSSxaog6akbLnF+4bUJbnOCcUIQYjybN/LSpN2N+j1Gr962P6iHC3eL fMRkbDTyJtF/iCLH3kDdoXSrK7C3fQsSpA4xYfMg2QaBSxYMM8IXT3k9N1F1kEd/gkuJ e7vmCLpVY/w1WP8vO50WKCekGfKgevkQx+bpxnVLc8xeSyUwbSEJl2ykVn+XPblnSxzg wBJWF4/9xpimB0ec7bPm0OB8IVxh7ZR1GMSGR3Y5PDyKPV7MfDzBppiBqdqoWLZXKVjD +Z8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m3ctSadbE0w1fwgAlbODWFAg6/Dlpm1WeYBp6eN3uX8=; b=DNOl6Q/2Yhb3n2vLOFiAfZHiQPga2ic0S4ZxXoInaJMZUf2yXE8z6hpbxJYXp543Z5 DDr8PkyUUa6ukWuVrVyWZhRNlo9GkeuJkClnqwmnL7uRj9JfGQ2GqrGJs0U/Z0jldgc0 xolbpnFKPjc4VTxgX1QrNcSdH/5JcLr3G+Hgx8XvjuArbD9EIySBhD/nitVrikfLtMW1 utqTdXlE+2qRdRuL8LGFriJxoQlyN7C/FJ04JoYS5qSiXmAh+WCGNwo+gbFRNSlsOavF lebu89eDflQEVdtmebBFIkNlCpWNqaAUmmQYWpDnqeStFII9LBvY/eKKHOJOfGvXyZ5N Yxcw== X-Gm-Message-State: AMCzsaUZmTmGLWa3Wf/Ru1NKMeg6HeeNujJKojPKmfyFhokGbqqC8Gfz McVDHK7lxbVvVpdoqRIrRu6d/iX4kx6U0og5Kjk= X-Google-Smtp-Source: AOwi7QCMBTy5s472R6VHimBuytjQp8tKanPUD09eRb0/Q8QVWuAfQ2HUG9xRZ7EvRkgAuuv3PbchogZucYHJtK0K9Fc= X-Received: by 10.28.29.68 with SMTP id d65mr69849wmd.93.1507244424085; Thu, 05 Oct 2017 16:00:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.196 with HTTP; Thu, 5 Oct 2017 16:00:23 -0700 (PDT) In-Reply-To: References: <1507238672.86205.250.camel@freebsd.org> From: David Goldblatt Date: Thu, 5 Oct 2017 16:00:23 -0700 Message-ID: Subject: Re: C++ in jemalloc To: Warner Losh Cc: Ian Lepore , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 23:00:26 -0000 (apologies if you receive this twice; I subscribed to the list in order to flip the needs-moderation bit for my posts). So it sounds like C++03 (or rather, the version of C++ supported by g++ 4.2) will be fine. Is C++11 a no-go, without breaking libc on non-Clang architectures? (It isn't clear to me if having to use the ports gcc to build was unfortunate or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the core implementation (we currently have to maintain our own backport of C11 atomics, for instance), but would be really helpful in the test suite (because of how much syntactically simpler it is to, say, spin up a bunch of threads to hammer a local instance of a data structure). On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > > > On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > >> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >> > wrote: >> > >> > > >> > > Hi all, >> > > >> > > The jemalloc developers have wanted to start using C++ for a while, to >> > > enable some targeted refactorings of code we have trouble maintaining >> due >> > > to brittleness or complexity (e.g. moving thousand line macro >> definitions >> > > to templates, changing the build->extract symbols->rebuild mangling >> scheme >> > > for internal symbols to one using C++ namespaces). We'd been holding >> off >> > > because we thought that FreeBSD base all had to compile on GCC 4.2, in >> > > order to support some esoteric architectures[1]. >> > > >> > > The other day though, I noticed that there is some C++ shipping with >> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >> HACKING >> > > document that C++11 is a minimum for FreeBSD 11). This, combined with >> the >> > > fact that ports now points to a modern gcc, makes me think we were >> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >> > > >> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >> build? >> > > We will of course not use exceptions, RTTI, global constructors, the >> C++ >> > > stdlib, or anything else that might affect C source or link >> compatibility. >> > > >> > > Thanks, >> > > David (on behalf of the jemalloc developers >> > > >> > > [1] That being said, we don't compile or test on those architectures, >> and >> > > so probably don't work there in the first place if I'm being honest. >> But >> > > we'd also like to avoid making that a permanent state of affairs that >> can't >> > > be changed. >> > > >> > For FreeBSD 10 and earlier, this would likely break all architectures >> that >> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >> clang, >> > but not super well. For FreeBSD 12, we're getting close for everything >> > except sparc64 (whose fate has not yet been finally decided). >> > >> > So for the popular architectures, this arrangement might work. For >> building >> > with external toolchains, it might also work. Some of the less popular >> > architectures may be a problem. >> > >> > Does that help? It isn't completely cut and dried, but it should be >> helpful >> > for you making a decision. >> > >> > Warner >> >> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >> 2006. What am I missing here that keeps this answer from being a >> simple "go for it"? >> >> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >> may require C++11, but that was likely the author's choice given that >> there was no requirement for it to work on pre-clang versions of >> freebsd). >> > > It's the ubiquity of C++11 is why I didn't just say "Go for it". > > Warner > From owner-freebsd-current@freebsd.org Thu Oct 5 23:13:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09066E451AF for ; Thu, 5 Oct 2017 23:13:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 BF70F65DB6 for ; Thu, 5 Oct 2017 23:13:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id m16so6341399iod.1 for ; Thu, 05 Oct 2017 16:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=o4gPzBlPbwbezKasByGTAkq52EDIgVnLx/OaXQjP7bA=; b=bVm93UUGiYdHDFYnyxE5I6UtV7G1g9dSaKP6sMMpv7O9Z7t1MgERpb7ILzPHg3pQQq HgqI6tvADXYbHx3QUecJpX4wEeVqVrzrEqa28Pk4MZlbHdAN6bSSraFLYuETLAUsoH9r +yeC2Yl4wjRjZgtR3WqETk2FbX1dTtgfVpYuoBo+EE0T7EFu4uB1jTZ6/BcWYY5dMraC KjXeDGVc6U1ZfLRyGpkMrYTSG/zBhFqUB5gtV87lhplp/sDjjfLOMtLu/RdnMtPvizyr K66gN0PKV0NMeXX7l2FVYHf5Vhfhx3ozJfGfXKF3fXuLK1pl6ICNMgSy7Ju6D9J0iYhK j/kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=o4gPzBlPbwbezKasByGTAkq52EDIgVnLx/OaXQjP7bA=; b=Xr7tDr0me0G3CWxH4vbA+HXNQrlfrPqKc71sbOK7uiFENQS9GHp3LCnF6d6T2mVwjK AZaGqGANxOD/v/AL5JBoGzkqYkJ3/cnFAPESiB+DsGYEF+let/fDuQsdy7HN07dvqpQV eHhljWJGmYYiHsoFBrMgLYjFeuG3EtfEqie8O9TuOiNqbIsgvyxfk++iuoeG9ZUyZxrq kK7VWebCYAaGb0yopX6bm2zKunsSd+qB5KuW7QdKXZXP2qFAHQXjgyxdiR2XNmRCKy1t ye4pooDo3VadcvV81SYh6wwJdfY8AWpyg3OHdfGxDV67PVHvPjh+dz03u5j4qGlGinON yK9w== X-Gm-Message-State: AMCzsaXYdRxcSw2RGdBQE0e9pVAgf2EAjRVPsxFpOgImF5irqAgbrIRk /71SLKrKykrJFHMow94v0ezCxOZ8caWekuVHzASbOQ== X-Google-Smtp-Source: AOwi7QCjvtx5wUMFOMTcb49EIYod2hqkYz28mUsEZCmfTCm563y/cCD8Pirkyasev4dBXhc8d86bD/0Lr3OczNHpJIg= X-Received: by 10.107.185.7 with SMTP id j7mr315188iof.221.1507245189089; Thu, 05 Oct 2017 16:13:09 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 16:13:08 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] In-Reply-To: References: <1507238672.86205.250.camel@freebsd.org> From: Warner Losh Date: Thu, 5 Oct 2017 16:13:08 -0700 X-Google-Sender-Auth: o1y0hM_hIcDg5tgONdAdjEnqZbU Message-ID: Subject: Re: C++ in jemalloc To: David Goldblatt Cc: Ian Lepore , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 23:13:10 -0000 Today C++11 is a no-go generally due to the lagging architectures needing gcc 4.2. However, that answer might change soon. Would it be easy for you to avoid C++11, or would that cause you significant pain? And what's the timeline you'd be releasing a new jemalloc requiring this stuff? The answers might change the 'no-go' to 'ok'. Warner On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt wrote: > So it sounds like C++03 (or rather, the version of C++ supported by g++ > 4.2) will be fine. > > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It > isn't clear to me if having to use the ports gcc to build was unfortunate > or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the > core implementation (we currently have to maintain our own backport of C11 > atomics, for instance), but would be really helpful in the test suite > (because of how much syntactically simpler it is to, say, spin up a bunch > of threads to hammer a local instance of a data structure). > > - David > > On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > >> >> >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: >> >>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >>> > wrote: >>> > >>> > > >>> > > Hi all, >>> > > >>> > > The jemalloc developers have wanted to start using C++ for a while, >>> to >>> > > enable some targeted refactorings of code we have trouble >>> maintaining due >>> > > to brittleness or complexity (e.g. moving thousand line macro >>> definitions >>> > > to templates, changing the build->extract symbols->rebuild mangling >>> scheme >>> > > for internal symbols to one using C++ namespaces). We'd been holding >>> off >>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, >>> in >>> > > order to support some esoteric architectures[1]. >>> > > >>> > > The other day though, I noticed that there is some C++ shipping with >>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >>> HACKING >>> > > document that C++11 is a minimum for FreeBSD 11). This, combined >>> with the >>> > > fact that ports now points to a modern gcc, makes me think we were >>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >>> > > >>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >>> build? >>> > > We will of course not use exceptions, RTTI, global constructors, the >>> C++ >>> > > stdlib, or anything else that might affect C source or link >>> compatibility. >>> > > >>> > > Thanks, >>> > > David (on behalf of the jemalloc developers >>> > > >>> > > [1] That being said, we don't compile or test on those >>> architectures, and >>> > > so probably don't work there in the first place if I'm being honest. >>> But >>> > > we'd also like to avoid making that a permanent state of affairs >>> that can't >>> > > be changed. >>> > > >>> > For FreeBSD 10 and earlier, this would likely break all architectures >>> that >>> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >>> clang, >>> > but not super well. For FreeBSD 12, we're getting close for everything >>> > except sparc64 (whose fate has not yet been finally decided). >>> > >>> > So for the popular architectures, this arrangement might work. For >>> building >>> > with external toolchains, it might also work. Some of the less popular >>> > architectures may be a problem. >>> > >>> > Does that help? It isn't completely cut and dried, but it should be >>> helpful >>> > for you making a decision. >>> > >>> > Warner >>> >>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >>> 2006. What am I missing here that keeps this answer from being a >>> simple "go for it"? >>> >>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >>> may require C++11, but that was likely the author's choice given that >>> there was no requirement for it to work on pre-clang versions of >>> freebsd). >>> >> >> It's the ubiquity of C++11 is why I didn't just say "Go for it". >> >> Warner >> > > From owner-freebsd-current@freebsd.org Thu Oct 5 23:50:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B669E459EF for ; Thu, 5 Oct 2017 23:50:35 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08A6166BA9; Thu, 5 Oct 2017 23:50:35 +0000 (UTC) (envelope-from davidtgoldblatt@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id l68so4947802wmd.5; Thu, 05 Oct 2017 16:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oe3EsbIq4kL75cqtZN62l5nQfnIgb9hSTdUDAQREF/k=; b=AvhTgcNNXbrU4ZRJolOcFLs8qWRrPbNnl9sJ6HS0eKzctw7GC+BHXHdKvooZopUTBN MiImUkaMtKQsT17VnXCgo8S19jvlspSu52tjVqcSxCdb8H4iOuv5e0evMjGPMfhOv/j7 PQ0b9YCHnOuH4I1E70Qm/8CN3uPy33j5PQSuGvqA+lzusDdxe71+izostM5yT9oJgu46 mWI0PH/9DfhRmU7RZVXqwIWHxLbWeg88/oY3Nm58BUsLeKv5oON8ESzX1d7GrRc9Tz0H aoHP4mvbOkx/osqByOJ09KcAG2J1lMLkdAJlTzkxTDekUbkvxaZCLavHvdF55Qf84F0b YEIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oe3EsbIq4kL75cqtZN62l5nQfnIgb9hSTdUDAQREF/k=; b=A0EyxGCXAkeiEr0P9eEX5r3NIfSn4Z0UVwkqMdwIZqYgGBOgeR41nIPIHlfjenqQbm WDshbrMVGqr2y4NeNwtUV4ugVhnwWQSoCvfT8/iu+606D1AUzz4h06dXBBpU2yAK9dXa ZYek4lJOY0obG3vz7uxtHXTS/5CBuGrkDVJOc8Fnr5BbmVQKmyliNevMGLwmraSH7s2C BkoepsWFKqax5UNhN+Wo/wRR0ZAajY94ZYUymx+ihJG/5dCOPwkDLV/5Yf1YX8sGQRx6 ASNQLTdzCqYcGgQCtNxvn9p5rhoBkCO7z4RCW/W9bY3UgwYr6cgGlFg9Hb69CHbNxMgE nnCg== X-Gm-Message-State: AMCzsaU9McisIaNJUeUVNpfWtHEZMdZFmks1hVEjxBAa83jDZDsaJluW x/Oo9DGJXQf62NHjW0wjeaza1kE/ciCv/XaNRNL3cNjBJuU= X-Google-Smtp-Source: AOwi7QAGDFKjMmKdgkwZo+Ohemkkq8GhK3HhSfhG8IUmXDsSL6nlRao9E6VuYaOWsP1g9yAG6GX+uQ2pW3oJvIh1so8= X-Received: by 10.28.11.133 with SMTP id 127mr114996wml.81.1507247433508; Thu, 05 Oct 2017 16:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.196 with HTTP; Thu, 5 Oct 2017 16:50:32 -0700 (PDT) In-Reply-To: References: <1507238672.86205.250.camel@freebsd.org> From: David Goldblatt Date: Thu, 5 Oct 2017 16:50:32 -0700 Message-ID: Subject: Re: C++ in jemalloc To: Warner Losh Cc: Ian Lepore , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 23:50:35 -0000 We can avoid it in the short term without a ton of pain. In the long run it would be nice to have, but I wouldn't want to tie our release schedule to FreeBSD's too tightly (our CI is improving to the point where the tip of the dev branch gets tested about as well as releases would be, so we're trying to de-emphasize release vs. non-release versions). Do you have a sense of when the situation might change (if only so I know when to check back)? Thanks for the replies on this, they've been super helpful. - David On Thu, Oct 5, 2017 at 4:13 PM, Warner Losh wrote: > Today C++11 is a no-go generally due to the lagging architectures needing > gcc 4.2. > > However, that answer might change soon. Would it be easy for you to avoid > C++11, or would that cause you significant pain? And what's the timeline > you'd be releasing a new jemalloc requiring this stuff? The answers might > change the 'no-go' to 'ok'. > > Warner > > > On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt > wrote: > >> So it sounds like C++03 (or rather, the version of C++ supported by g++ >> 4.2) will be fine. >> >> Is C++11 a no-go, without breaking libc on non-Clang architectures? (It >> isn't clear to me if having to use the ports gcc to build was unfortunate >> or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the >> core implementation (we currently have to maintain our own backport of C11 >> atomics, for instance), but would be really helpful in the test suite >> (because of how much syntactically simpler it is to, say, spin up a bunch >> of threads to hammer a local instance of a data structure). >> >> - David >> >> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: >> >>> >>> >>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: >>> >>>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >>>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >>>> > wrote: >>>> > >>>> > > >>>> > > Hi all, >>>> > > >>>> > > The jemalloc developers have wanted to start using C++ for a while, >>>> to >>>> > > enable some targeted refactorings of code we have trouble >>>> maintaining due >>>> > > to brittleness or complexity (e.g. moving thousand line macro >>>> definitions >>>> > > to templates, changing the build->extract symbols->rebuild mangling >>>> scheme >>>> > > for internal symbols to one using C++ namespaces). We'd been >>>> holding off >>>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, >>>> in >>>> > > order to support some esoteric architectures[1]. >>>> > > >>>> > > The other day though, I noticed that there is some C++ shipping with >>>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >>>> HACKING >>>> > > document that C++11 is a minimum for FreeBSD 11). This, combined >>>> with the >>>> > > fact that ports now points to a modern gcc, makes me think we were >>>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >>>> > > >>>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >>>> build? >>>> > > We will of course not use exceptions, RTTI, global constructors, >>>> the C++ >>>> > > stdlib, or anything else that might affect C source or link >>>> compatibility. >>>> > > >>>> > > Thanks, >>>> > > David (on behalf of the jemalloc developers >>>> > > >>>> > > [1] That being said, we don't compile or test on those >>>> architectures, and >>>> > > so probably don't work there in the first place if I'm being >>>> honest. But >>>> > > we'd also like to avoid making that a permanent state of affairs >>>> that can't >>>> > > be changed. >>>> > > >>>> > For FreeBSD 10 and earlier, this would likely break all architectures >>>> that >>>> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >>>> clang, >>>> > but not super well. For FreeBSD 12, we're getting close for everything >>>> > except sparc64 (whose fate has not yet been finally decided). >>>> > >>>> > So for the popular architectures, this arrangement might work. For >>>> building >>>> > with external toolchains, it might also work. Some of the less popular >>>> > architectures may be a problem. >>>> > >>>> > Does that help? It isn't completely cut and dried, but it should be >>>> helpful >>>> > for you making a decision. >>>> > >>>> > Warner >>>> >>>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >>>> 2006. What am I missing here that keeps this answer from being a >>>> simple "go for it"? >>>> >>>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >>>> may require C++11, but that was likely the author's choice given that >>>> there was no requirement for it to work on pre-clang versions of >>>> freebsd). >>>> >>> >>> It's the ubiquity of C++11 is why I didn't just say "Go for it". >>> >>> Warner >>> >> >> > From owner-freebsd-current@freebsd.org Fri Oct 6 00:05:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61696E020C7 for ; Fri, 6 Oct 2017 00:05:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3810B673DC; Fri, 6 Oct 2017 00:05:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 357AE10A8BC; Thu, 5 Oct 2017 20:05:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Warner Losh , David Goldblatt , Ian Lepore Subject: Re: C++ in jemalloc Date: Thu, 05 Oct 2017 16:34:29 -0700 Message-ID: <3760998.usdmS98HcN@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 05 Oct 2017 20:05:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 00:05:32 -0000 In particular, it is expected that FreeBSD 12 will not ship with GCC 4.2 and that all supported architectures in FreeBSD 12 will be using a C++11-capable toolchain (either external GCC or in-tree clang). However, older releases will still be restricted to C++03 (or whatever GCC 4.2 supports) including future releases on FreeBSD 11. Also, FreeBSD-HEAD's tree is not yet in a position where all architectures are using a C++11-capable toolchain. On Thursday, October 05, 2017 04:13:08 PM Warner Losh wrote: > Today C++11 is a no-go generally due to the lagging architectures needing > gcc 4.2. > > However, that answer might change soon. Would it be easy for you to avoid > C++11, or would that cause you significant pain? And what's the timeline > you'd be releasing a new jemalloc requiring this stuff? The answers might > change the 'no-go' to 'ok'. > > Warner > > > On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt > wrote: > > > So it sounds like C++03 (or rather, the version of C++ supported by g++ > > 4.2) will be fine. > > > > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It > > isn't clear to me if having to use the ports gcc to build was unfortunate > > or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the > > core implementation (we currently have to maintain our own backport of C11 > > atomics, for instance), but would be really helpful in the test suite > > (because of how much syntactically simpler it is to, say, spin up a bunch > > of threads to hammer a local instance of a data structure). > > > > - David > > > > On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > > > >> > >> > >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > >> > >>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > >>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > >>> > wrote: > >>> > > >>> > > > >>> > > Hi all, > >>> > > > >>> > > The jemalloc developers have wanted to start using C++ for a while, > >>> to > >>> > > enable some targeted refactorings of code we have trouble > >>> maintaining due > >>> > > to brittleness or complexity (e.g. moving thousand line macro > >>> definitions > >>> > > to templates, changing the build->extract symbols->rebuild mangling > >>> scheme > >>> > > for internal symbols to one using C++ namespaces). We'd been holding > >>> off > >>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, > >>> in > >>> > > order to support some esoteric architectures[1]. > >>> > > > >>> > > The other day though, I noticed that there is some C++ shipping with > >>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the > >>> HACKING > >>> > > document that C++11 is a minimum for FreeBSD 11). This, combined > >>> with the > >>> > > fact that ports now points to a modern gcc, makes me think we were > >>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. > >>> > > > >>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to > >>> build? > >>> > > We will of course not use exceptions, RTTI, global constructors, the > >>> C++ > >>> > > stdlib, or anything else that might affect C source or link > >>> compatibility. > >>> > > > >>> > > Thanks, > >>> > > David (on behalf of the jemalloc developers > >>> > > > >>> > > [1] That being said, we don't compile or test on those > >>> architectures, and > >>> > > so probably don't work there in the first place if I'm being honest. > >>> But > >>> > > we'd also like to avoid making that a permanent state of affairs > >>> that can't > >>> > > be changed. > >>> > > > >>> > For FreeBSD 10 and earlier, this would likely break all architectures > >>> that > >>> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by > >>> clang, > >>> > but not super well. For FreeBSD 12, we're getting close for everything > >>> > except sparc64 (whose fate has not yet been finally decided). > >>> > > >>> > So for the popular architectures, this arrangement might work. For > >>> building > >>> > with external toolchains, it might also work. Some of the less popular > >>> > architectures may be a problem. > >>> > > >>> > Does that help? It isn't completely cut and dried, but it should be > >>> helpful > >>> > for you making a decision. > >>> > > >>> > Warner > >>> > >>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like > >>> 2006. What am I missing here that keeps this answer from being a > >>> simple "go for it"? > >>> > >>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC > >>> may require C++11, but that was likely the author's choice given that > >>> there was no requirement for it to work on pre-clang versions of > >>> freebsd). > >>> > >> > >> It's the ubiquity of C++11 is why I didn't just say "Go for it". > >> > >> Warner > >> > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- John Baldwin From owner-freebsd-current@freebsd.org Fri Oct 6 03:39:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6686E259CD for ; Fri, 6 Oct 2017 03:39:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 6294D6CB90 for ; Fri, 6 Oct 2017 03:39:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id f72so8619366ioj.5 for ; Thu, 05 Oct 2017 20:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xr9slmh/JWuj8bqDgkhJnBHrTiTPeMTR4myEPJV5i3g=; b=FOJvpGmMDZGwzpaHUpRvgzLAX+mNxix5ckFjLJuqwAk164FcqP0IQEg2UwvTxErGDS OE8evf/7yjxobmuxFmM2xz7HFGnxEoZ9bfgopNflt0wx8SR+TAHnh3x0cu6rdYS1P0X3 aRdO79ttZllCUmLaP2c1HhfOVIUaf//Xx7DjPyu+V60tg0sQBfN1HwFusGXwVQsK/plF mLszzAWXH4cqwHilGnz8N0xKNTs2MWAOwBX9nEA/UdUxUxUVxA1r/yhKsxvClqP1gidz K8cP4EBRxFmOt3f9a4tClzA56bfeT55mEJmq00gxyhJikVX2ik6uMUrFHr8Ws4vA+QkE INcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xr9slmh/JWuj8bqDgkhJnBHrTiTPeMTR4myEPJV5i3g=; b=nXVxdhgd+PQbgCBxzzUzVK3eq5TXX4xyDeEbGUQGkFp4veLvAl+dp+EOA37OTq/Yy5 YlyfFk7PpHBHbG8Kv3ggHql4qtm6EZne7HauqWT3vbLKNcPt9BPNNQVDUVRfxGCZ8yRz pM1siy1YwpzrtuURSjSIhhviatwn2D5seavKqb5KiqWq75DWnFmlEQUqSZDnsZdmP3nW lEfSeVmWBUD7XDIgu1IDbeJT2UM+9J2SCXiEhDscmLC0Pj7JXXkqjtiBNLQikqGfzQBq zGHizDWEBqVJXhaQ2Wo9dDr5IXcijLRzyMVa7waiz9D4nKk7uvjSuxgqcgerQ2F4VUi9 Bo6g== X-Gm-Message-State: AMCzsaXJEFTLbb1jDtgTmH3gbzk09PNnTIuoHKdXMY0LHNAMtZBGQKCN wQc0xlUkGV3j6VglwzocjdSJzi3M8Y5FfF2TbXRfiw== X-Google-Smtp-Source: AOwi7QCv4BFmPPeE7CZw92llf0tBV+Jqu1jOMeYk/l6ZjcuQcUYdZQuDk+ouR/4mTpk73US8rh3TKBXHxzTGKzvX7OI= X-Received: by 10.107.68.6 with SMTP id r6mr929548ioa.282.1507261177642; Thu, 05 Oct 2017 20:39:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 20:39:37 -0700 (PDT) X-Originating-IP: [208.185.168.99] In-Reply-To: References: <1507238672.86205.250.camel@freebsd.org> From: Warner Losh Date: Thu, 5 Oct 2017 20:39:37 -0700 X-Google-Sender-Auth: Hy_4DYVzA4Ynk6k5ghiKX4MRcAw Message-ID: Subject: Re: C++ in jemalloc To: David Goldblatt Cc: Ian Lepore , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 03:39:38 -0000 I'm guessing a realistic timeline for us would be on the order of 3 to 6 months. We've been dithering on this issue for a while, and your request seems as good a time as any to get people off the fence... So, if you are targeting FreeBSD 12, then in that time frame, there'd be no issues with C++11 in the form you characterized. FreeBSD 11.x couldn't handle requiring a c++11 compiler to build though, and we're planning another release of that soon. Warner On Thu, Oct 5, 2017 at 4:50 PM, David Goldblatt wrote: > We can avoid it in the short term without a ton of pain. In the long run > it would be nice to have, but I wouldn't want to tie our release schedule > to FreeBSD's too tightly (our CI is improving to the point where the tip of > the dev branch gets tested about as well as releases would be, so we're > trying to de-emphasize release vs. non-release versions). Do you have a > sense of when the situation might change (if only so I know when to check > back)? > > Thanks for the replies on this, they've been super helpful. > > - David > > > On Thu, Oct 5, 2017 at 4:13 PM, Warner Losh wrote: > >> Today C++11 is a no-go generally due to the lagging architectures needing >> gcc 4.2. >> >> However, that answer might change soon. Would it be easy for you to avoid >> C++11, or would that cause you significant pain? And what's the timeline >> you'd be releasing a new jemalloc requiring this stuff? The answers might >> change the 'no-go' to 'ok'. >> >> Warner >> >> >> On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt < >> davidtgoldblatt@gmail.com> wrote: >> >>> So it sounds like C++03 (or rather, the version of C++ supported by g++ >>> 4.2) will be fine. >>> >>> > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It >>> isn't clear to me if having to use the ports gcc to build was unfortunate >>> or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the >>> core implementation (we currently have to maintain our own backport of C11 >>> atomics, for instance), but would be really helpful in the test suite >>> (because of how much syntactically simpler it is to, say, spin up a bunch >>> of threads to hammer a local instance of a data structure). >>> >>> - David >>> >>> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: >>> >>>> >>>> >>>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: >>>> >>>>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >>>>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >>>>> > wrote: >>>>> > >>>>> > > >>>>> > > Hi all, >>>>> > > >>>>> > > The jemalloc developers have wanted to start using C++ for a >>>>> while, to >>>>> > > enable some targeted refactorings of code we have trouble >>>>> maintaining due >>>>> > > to brittleness or complexity (e.g. moving thousand line macro >>>>> definitions >>>>> > > to templates, changing the build->extract symbols->rebuild >>>>> mangling scheme >>>>> > > for internal symbols to one using C++ namespaces). We'd been >>>>> holding off >>>>> > > because we thought that FreeBSD base all had to compile on GCC >>>>> 4.2, in >>>>> > > order to support some esoteric architectures[1]. >>>>> > > >>>>> > > The other day though, I noticed that there is some C++ shipping >>>>> with >>>>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >>>>> HACKING >>>>> > > document that C++11 is a minimum for FreeBSD 11). This, combined >>>>> with the >>>>> > > fact that ports now points to a modern gcc, makes me think we were >>>>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >>>>> > > >>>>> > > Am I right? Will anything break if jemalloc needs a C++ compiler >>>>> to build? >>>>> > > We will of course not use exceptions, RTTI, global constructors, >>>>> the C++ >>>>> > > stdlib, or anything else that might affect C source or link >>>>> compatibility. >>>>> > > >>>>> > > Thanks, >>>>> > > David (on behalf of the jemalloc developers >>>>> > > >>>>> > > [1] That being said, we don't compile or test on those >>>>> architectures, and >>>>> > > so probably don't work there in the first place if I'm being >>>>> honest. But >>>>> > > we'd also like to avoid making that a permanent state of affairs >>>>> that can't >>>>> > > be changed. >>>>> > > >>>>> > For FreeBSD 10 and earlier, this would likely break all >>>>> architectures that >>>>> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >>>>> clang, >>>>> > but not super well. For FreeBSD 12, we're getting close for >>>>> everything >>>>> > except sparc64 (whose fate has not yet been finally decided). >>>>> > >>>>> > So for the popular architectures, this arrangement might work. For >>>>> building >>>>> > with external toolchains, it might also work. Some of the less >>>>> popular >>>>> > architectures may be a problem. >>>>> > >>>>> > Does that help? It isn't completely cut and dried, but it should be >>>>> helpful >>>>> > for you making a decision. >>>>> > >>>>> > Warner >>>>> >>>>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >>>>> 2006. What am I missing here that keeps this answer from being a >>>>> simple "go for it"? >>>>> >>>>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >>>>> may require C++11, but that was likely the author's choice given that >>>>> there was no requirement for it to work on pre-clang versions of >>>>> freebsd). >>>>> >>>> >>>> It's the ubiquity of C++11 is why I didn't just say "Go for it". >>>> >>>> Warner >>>> >>> >>> >> > From owner-freebsd-current@freebsd.org Fri Oct 6 05:05:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 739E7E27440 for ; Fri, 6 Oct 2017 05:05:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 2C4E96E9DE for ; Fri, 6 Oct 2017 05:05:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2303 invoked from network); 6 Oct 2017 04:58:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Oct 2017 04:58:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 06 Oct 2017 00:58:34 -0400 (EDT) Received: (qmail 19245 invoked from network); 6 Oct 2017 04:58:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Oct 2017 04:58:34 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD546EC94C3; Thu, 5 Oct 2017 21:58:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc Message-Id: Date: Thu, 5 Oct 2017 21:58:33 -0700 To: Warner Losh , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 05:05:16 -0000 Warner Losh imp at bsdimp.com wrote on Thu Oct 5 21:01:26 UTC 2017 : > Starting in FreeBSD 11, arm and powerpc are supported by clang, > but not super well. For FreeBSD 12, we're getting close for everything > except sparc64 (whose fate has not yet been finally decided). My understanding of the powerpc and powerpc64 status follows. This is based on my use of head via clang as much as I can for them. For TARGET_ARCH=3Dpowerpc64 and TARGET_ARCH=3Dpowerpc : lld is far from working last I knew. (I've focused more on the compilers for testing, using other linkers and such.) [lldb may be in a similar state for powerpc64. It does not build for powerpc.] clang 5 (and 4) generated code crashes on any thrown C++ exception. For example: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } crashes. Luckily most kernel and world code that I actively use does not throw C++ exceptions in my use. But devel/kyua is majorly broken by the C++ exception issue: It makes extensive use of C++ exceptions. In my view that disqualifies clang as being "close": I view my activity as a hack until devel/kyua is generally operable and so available for use in testing. clang 5 currently can not build the TARGET_ARCH=3Dpowerpc kernel. (I was able to back in clang 4 days --but the resultant build failed to execute init fully after finishing the prior boot activity.) For the 32-bit context I use gcc 4.2.1 for building the kernel and clang 5 for building the world, system binutils=20 in use in both cases. I do build the kernel and world for TARGET_ARCH=3Dpowerpc64 via system clang 5. But I use ports binutils as well in order for this to finish and work overall. As for more modern devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc) versions being used to build the world and kernel for powerpc64 I've never been able to get lib32 on powerpc64 to work via such a build: it builds but fails to execute from dereferencing via an R30 that has an inappropriate value for the attempt ( lib32/crtbeginS.o code in _init in /usr/lib32/libc.so.* ). (The clang-based builds do not have this problem.) It has been a while since I've done devel/powerpc64-gcc experiments. I'm not aware of a devel/powerpc-xtoolchain-gcc as an alternative for 32-bit powerpc targeting. You may want to skip the below src.conf's and so reading the rest of this note. Example src.conf for targeting powerpc64 for buildkernel and buildworld via clang: (Note: most of my more recent activity has cross built from amd64 instead of doing self-hosted. That way more folks can try the same for issues where builds stop.) # more = ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # # Avoid converts between pointers to integer types with different sign = [-Werror,-Wpointer-sign] # and such from blocking the build. WERROR=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 # # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX # binding automatically. # XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld .export XLD .endif For powerpc via clang (world anyway): # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D As for powerpc64-xtoolchain-gcc targeting powerpc64: # more ~/src.configs/src.conf.powerpc64-xtoolchain-gcc.amd64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Avoid db_trace.o getting: # calling '__builtin_frame_address' with a nonzero argument is unsafe # as an error? Other such points as well. WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-current@freebsd.org Fri Oct 6 08:58:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EA34E31225 for ; Fri, 6 Oct 2017 08:58:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 279B975EC9; Fri, 6 Oct 2017 08:58:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v968wolO082600 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Oct 2017 11:58:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v968wolO082600 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v968wolT082599; Fri, 6 Oct 2017 11:58:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 Oct 2017 11:58:50 +0300 From: Konstantin Belousov To: David Goldblatt Cc: Warner Losh , Ian Lepore , FreeBSD Current Subject: Re: C++ in jemalloc Message-ID: <20171006085850.GQ95911@kib.kiev.ua> References: <1507238672.86205.250.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 08:58:57 -0000 On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. Note that these are just usermode utilities, which implementation language is not too important. If we considered ghc or rustc to be acceptable dependency for utilities, then they could be implemented in Haskell or Rust as well. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. I wonder how can you guarantee that for current and future compilers without having the standard saying and compiler facilities to ensure that. See below. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. On Thu, Oct 05, 2017 at 04:50:32PM -0700, David Goldblatt wrote: > We can avoid it in the short term without a ton of pain. In the long run it > would be nice to have, but I wouldn't want to tie our release schedule to > FreeBSD's too tightly (our CI is improving to the point where the tip of > the dev branch gets tested about as well as releases would be, so we're > trying to de-emphasize release vs. non-release versions). Do you have a > sense of when the situation might change (if only so I know when to check > back)? > > Thanks for the replies on this, they've been super helpful. I do not think so. You are talking about importing C++ code into libc. Libc _implements_ C runtime, which is a dependency of any C++ runtime. That is, we cannot allow C++ runtime to be dragged into libc. C++ freestanding implementation, by the standard, is required to provide the runtime typeinfo, exceptions, intialization and termination support (i.e. atexit/cxa_atexit and most important cxa_thread_atexit, if you use TLS) and so on. It clearly gives the cycle in the dependencies. There is no requirement on the compilers to not use these features in unexpected ways, and looking at the current compiler evolution, I do expect that these features would bite us simply because we allowed C++ code in libc. We already have some issues die to the jemalloc reliance on pthreads, which makes the bootstraping a problem. We have to maintain the ugly fake init trick to postpone malloc for the mutexes backing store inside libthr to allow jemalloc to initialize without causing cyclic dependencies. Also, our C runtime (rtld/libc/libthr and perhaps libm) is currently only requires C compiler (and assembler and linker) to compile. Having C++ requirement for compilation, assuming the runtime issues I noted above are somewhat avoided, is also not a move I consider useful. Summary is that, in my opinion, requiring C++ compiler and working runtime for malloc(3) implementation is not desirable. If this goes in, low-level parts of the libc and whole libthr must grow private malloc implementation to not depend on libc malloc. Currently only rtld has private malloc (for similar reasons). From owner-freebsd-current@freebsd.org Fri Oct 6 13:10:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85B58E36C86 for ; Fri, 6 Oct 2017 13:10:25 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0989D828BA for ; Fri, 6 Oct 2017 13:10:24 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.14.205]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTwYX-1drUFN2hNp-00Qg6i for ; Fri, 06 Oct 2017 15:10:16 +0200 Date: Fri, 6 Oct 2017 15:10:08 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r324353: boot failure: failed with error 19 Message-ID: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/DZDOD3yG_/_/GEbiZMSo5xA"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:nTWvapItvUNRrzUGP8YdJmPPDcMzUBJpCEEkvc1Z1T88WJkGCNn AsgBnH++NFN95c9nYE8KUpYRRUP48Utq8Av5yNI9hsCUpiFuc2V4JCk5R8W98pGqgmn6V2R J78qoeCk1wrtbbFwCYkK4cOx1Vc7Z+xmcWNgyJieMXuv9Onbdg5WpxAdPXCjOWL02C1sTus W67YoG+erOWkD0f4xFfig== X-UI-Out-Filterresults: notjunk:1;V01:K0:cgeiSUUgP8A=:or7SdRfhXND3awNF1a6U2O k9xRUyqKM9gApLXJZdHgsNIR01zkypO8nFfWHRmWbp86o9jlW3v/83p1rREnwRANpa3JlWDZj jDM6ENBvTiIfvUiaENwTqPGGZy6a/M+LGki/3ZyLkattIBJRztjPbtenhdqidhd4BOGiqFBXa lTXWRNEJorcqWXk3dpayjhmsrxaFdBdWnvfoZnhNbLOqEAIwk28t6ScJKRcRN3ucOB/IAnUCE DrfF/xUVeKK+BCw8L09EAdljT4oaAE4hqDFgdk8QwtEF7i+Jjdb0OatMS1b7w0cN/yh7pPgfc Mi2l5eGEujZ8PLuzqlFDQCiFhvlF6KXkngkNedXxJ1BC1S5Q/ctrVCXFmm6jnyeknKyeRL6Rg zwI1eSun+gx1khFt1Msg+KoFHwq6bz/bRCaRkElAtQ6xeiESBCLXG81aurkb1eZ88VO+4ixBp fUchQD/RMXPXvOJyeE/KKO6QsXWtjBoyADL/t/FTHpoiQLHGe4T7Tp3juy6OsIwW/cSHOvowm QQs5sdUqF6Ym9gL7VmZ5do4PnkQEkuDuGnpeB5Au6rqneTHDddOorGgLb31eUtd5bdVAc8ZQP zEozpEc3cjnk4QHNAA09Q3nr52z6R7EwDFFVYFVdElx9GQH0QoqkwxgTbvhjvtB5SggTaxMr6 CbVsEUCHOFwUKf3DpbCTCVA3UX8n/Ze6RoB5QCkhTV9IR8REPpVDBnSRaXGtWsIPLoc3dXDWi PLkYdA8sNmR5LkqAxW2A3hhpLNVYRw/pVi9MpYjDpDGktAEQ5yyF6iLDBAEitUFLXuMBkRMSr D3UFbzMzM/n/LR1ME6NQ+F2LH2RXg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:10:25 -0000 --Sig_/DZDOD3yG_/_/GEbiZMSo5xA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I run a small appliance on an APU from PCengines. This box is bootet via SD= card, the image is created by a modified NanoBSD, which creates GPT/UEFI partitioning= and booting images. That worked until two days ago (I do not track the revision numer) when I w= rote (via dd) the last image out. Today, I tried to boot r324353 and it fails at tthe boo= t loader: mountroot: waiting for device /dev/ufs/dsks1a... Mounting from ufs:/dev/ufs/dsks1a failed with error 19. I can proceed by manually issuing at the loader propmpt ufs:/dev/gpt/dsks1a and booting proceeds as expected. =20 Something seems wrong with the UFS labeling lately. The gpt layout looks like this: gpart show -l: =3D> 40 60751792 mmcsd0 GPT (29G) 40 130 1 boot (65K) 170 6 - free - (3.0K) 176 2057288 2 dsks1a [bootme] (1.0G) 2057464 2061725 3 dsks2a (1.0G) 4119189 1048576 4 dsks3 (512M) 5167765 55584067 - free - (27G) =46rom dmesg. I can provide this last output: [...] mmcsd0: 31GB at mmc0 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]= ... uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 uhub2 on uhub1 uhub2: on = usbus1 uhub2: 4 ports with 4 removable, self powered mountroot: waiting for device /dev/ufs/dsks1a... Mounting from ufs:/dev/ufs/dsks1a failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/ufs/dsks1a vfs.root.mountfrom.options=3Dro Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[C= s []... mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... random: unblocking device. arc4random: no preloaded entropy cache Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. mountroot> Invalid file system specification. mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... arc4random: no preloaded entropy cache GEOM_ELI: Device gpt/swap.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware Link state changed to up [...] Can someone look into this? Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/DZDOD3yG_/_/GEbiZMSo5xA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdeAsAAKCRDS528fyFhY lITnAgCEK4ywBIP3QEURpYM+O7Ey3CEro54G2CfVPCGtZqW+NpNYVdVt/RbgLQcm PsgCaT6wK//PwxZRRPHJ4M8fn74LAf4qA63fiSqOESQqHSYme+0BwbTdmNBvcFPP OJy/ljwov/I4CRPu7EplRn/uziZV+uUCVoE4csirkMFiOkOsRwId =UiQz -----END PGP SIGNATURE----- --Sig_/DZDOD3yG_/_/GEbiZMSo5xA-- From owner-freebsd-current@freebsd.org Fri Oct 6 13:28:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0262CE37405 for ; Fri, 6 Oct 2017 13:28:00 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F6248350D for ; Fri, 6 Oct 2017 13:27:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v96DRqhQ028404 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Oct 2017 15:27:52 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v96DRqVQ028401; Fri, 6 Oct 2017 15:27:52 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 6 Oct 2017 15:27:52 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: "O. Hartmann" cc: FreeBSD CURRENT Subject: Re: r324353: boot failure: failed with error 19 In-Reply-To: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> Message-ID: References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:28:00 -0000 On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via SD card, the > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning and booting > images. > > That worked until two days ago (I do not track the revision numer) when I wrote (via dd) > the last image out. Today, I tried to boot r324353 and it fails at tthe boot loader: > > > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > I can proceed by manually issuing at the loader propmpt > > ufs:/dev/gpt/dsks1a > > and booting proceeds as expected. > > > Something seems wrong with the UFS labeling lately. > > The gpt layout looks like this: > > gpart show -l: > > => 40 60751792 mmcsd0 GPT (29G) > 40 130 1 boot (65K) > 170 6 - free - (3.0K) > 176 2057288 2 dsks1a [bootme] (1.0G) > 2057464 2061725 3 dsks2a (1.0G) > 4119189 1048576 4 dsks3 (512M) > 5167765 55584067 - free - (27G) For one, these are the GPT labels. Can you verify the UFS labels (volnames)? Try: dumpfs /dev/gpt/dsks1a > From dmesg. I can provide this last output: > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]... > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: on usbus1 > uhub2: 4 ports with 4 removable, self powered > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a > vfs.root.mountfrom.options=ro > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs []... > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > random: unblocking device. > arc4random: no preloaded entropy cache > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. This surely indicates a mangled UFS volname. Maybe you should rewrite the volname: tunefs -L dsk1a /dev/gpt/dsks1a Or is the volname misspelled? tunefs -L dsks1a /dev/gpt/dsks1a Or is /etc/fstab on the SD card corrupted? > mountroot> Invalid file system specification. > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > arc4random: no preloaded entropy cache > GEOM_ELI: Device gpt/swap.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > Link state changed to up > > [...] > > > Can someone look into this? > > Kind regards, > > Oliver -- Trond. From owner-freebsd-current@freebsd.org Fri Oct 6 14:10:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06B06E3826A for ; Fri, 6 Oct 2017 14:10:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C33611021 for ; Fri, 6 Oct 2017 14:10:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id h66so16191656ioh.11 for ; Fri, 06 Oct 2017 07:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9eV6uTNqoDXOBiZ6dKdrm2seMISfP8veOfx7StTohrg=; b=VEENXX3accyp6BfHfCOtD51QbiJ1MdBc8FHbI+uqaprZ9K9ZNgHtU2yHiWt0DOvIVz GTxQBSCUeq4BCg2m8yO3E8zrkCbuNgzYEvj4brHyYbohXYMH8JJUP5F3QUSPr49sXc3f Rdx1KnTFztKegUezlZ2Zp0HnNM/nkKiZ/3JY18r5ieNNUPWc+D0tn6XeozgfYUT1jgUM bwYisJZ7O9JqqD+tz4xehGDJipOI9W37g4GVoP+sw691hWuZXcESo7W4CPJkro0+/6sa bUBTdTd/mZJ2+HoASeTtMsFUWBwvJ4l4sggWE2al5SMvPiyUcKwyAzscynsYdi13/A7P 5gIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9eV6uTNqoDXOBiZ6dKdrm2seMISfP8veOfx7StTohrg=; b=b4h53UBbU54kbXrAtCF9d/3EJik2MGAkx6oZdFAw25H9wF708StjtUU6lGyoPzE05c KLN50WspqM1uc1iYIu4otjfUm47ubYC2D9CI/87AOqks61O0N7JLJjrVn9Bv7ylhJW2l i9GoZjUf9Sa/9IsrIVl7+ICVjMzWSJZinTluNvknQfTsk4Fhxgf93ooZNVLKWFyhLgTy DiF8a4njqD/lJ1JVynxMcx5Vcci2YF7oufLs4mHXXzVyMB5Puz+1+ihhVt/GnytVb60Y vt5+XY2vPqRSo9HTqMR7Ngc+h4HNkz4kYC82Bja0vrSYA4sFnC9pJcOUTWdXKy1htx4a 2PJA== X-Gm-Message-State: AMCzsaXfK8QHrWsSWMfS2OyCKEy9t80ahv7uG4ro+6NXrRF0QmnGwqt7 Lpx9EjNEVeB8AGiSdqLG86GHOmM++FzF5r9lF5yu3Q== X-Google-Smtp-Source: AOwi7QAuT8Gkgxj+PNKAKPbd08J3OKlbgtOs2oLZYsns0HJ7ihGTIpW2APaU922jfd/du3MPOGul8cRWsoPLvhaKOwE= X-Received: by 10.107.135.147 with SMTP id r19mr2714780ioi.26.1507299045036; Fri, 06 Oct 2017 07:10:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Fri, 6 Oct 2017 07:10:44 -0700 (PDT) X-Originating-IP: [192.173.66.161] In-Reply-To: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Fri, 6 Oct 2017 07:10:44 -0700 X-Google-Sender-Auth: CY9xqc_XBmrJIUdu9h2lo-qRCYM Message-ID: Subject: Re: r324353: boot failure: failed with error 19 To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:10:46 -0000 On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via > SD card, the > image is created by a modified NanoBSD, which creates GPT/UEFI > partitioning and booting > images. > > That worked until two days ago (I do not track the revision numer) when I > wrote (via dd) > the last image out. Today, I tried to boot r324353 and it fails at tthe > boot loader: > > > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > That's odd... But likely a race.... It could be that dd'ing the new partition, however, was made from an image that didn't have the proper ufs label. What's the rev of the last version that worked? Warner > I can proceed by manually issuing at the loader propmpt > > ufs:/dev/gpt/dsks1a > > and booting proceeds as expected. > > > Something seems wrong with the UFS labeling lately. > > The gpt layout looks like this: > > gpart show -l: > > =3D> 40 60751792 mmcsd0 GPT (29G) > 40 130 1 boot (65K) > 170 6 - free - (3.0K) > 176 2057288 2 dsks1a [bootme] (1.0G) > 2057464 2061725 3 dsks2a (1.0G) > 4119189 1048576 4 dsks3 (512M) > 5167765 55584067 - free - (27G) > > From dmesg. I can provide this last output: > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a > [ro]... > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: o= n > usbus1 > uhub2: 4 ports with 4 removable, self powered > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/ufs/dsks1a > vfs.root.mountfrom.options=3Dro > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[= [Cs > []... > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > random: unblocking device. > arc4random: no preloaded entropy cache > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error > 19. > > mountroot> Invalid file system specification. > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > arc4random: no preloaded entropy cache > GEOM_ELI: Device gpt/swap.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > Link state changed to up > > [...] > > > Can someone look into this? > > Kind regards, > > Oliver > -- > O. Hartmann > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s. 4 BDSG). > From owner-freebsd-current@freebsd.org Fri Oct 6 14:15:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65935E384D0 for ; Fri, 6 Oct 2017 14:15:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8E961450 for ; Fri, 6 Oct 2017 14:15:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id l23so13695798lfk.10 for ; Fri, 06 Oct 2017 07:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AgrrtHiY+RXBqUTB12UwCxHJwQ1HZ2PZwnwkTxIDquQ=; b=s1Pjzivnp+m9GLhaxyUqHQGA2Tl7BzJuEsAI0cu3/oymBFEdAlodQrbWzp9h904ZRh bor4z8stAD9ckmSWS5Z3OJw5zZ9U8VcUAwdHVrXo6gsr/jUmom1EBRAgMxN4lbUkMMav 1AlXXpQ3o9f5gKcHwY/BluWCQi/L+o+wmUR1hyVHrweT1ha84HF41I3F4w8zFRgQBTBJ umhFQQNP0aKtNtY/ScQ0JI2vac81ti+g95dNL7o8qlYIE3EuVduMpFNuBpEyehlOU3Lx HW3B1vW+C7N1u8X+QGM0CmUvYCPxZQP9sJ2OXtDO4CLO3sPhY+2jNtuK9QTDMXLTkE4p /CXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AgrrtHiY+RXBqUTB12UwCxHJwQ1HZ2PZwnwkTxIDquQ=; b=LR8HZHOGiSVU2WwRZ/4blgrxH40U7Qt/RfSrFPIt7igdYXcxKiWebmamAKlTFzeJgs Wi74URLfpHCHsrgZ5+0J1nmnfqBoQxdPmEBy6fp2LGxCqRVO74AJb6J5D95Yax+86Kmz fD+rmyRiI7NyCw4zZDxCrvCnGybeTet3I3N46YLHjRRLG35SHBMfrpc6bQ0Bdx2NiWDq 13fsHGg9lKsn7Mb+UWqRCcMTYNiRHAMKn23we7EJMSKVdjUcAX+Q8sNtX6gtfl1QPtQ5 NjjdMqoBUtPI72kDdyh3KLf6aTQcyqB/co2WRJn5a9iLZrs7DUlz4fkrAKnDzkyPAzPQ Wugg== X-Gm-Message-State: AMCzsaUru1ntiSTRmaVOEhgkKEgtstVaFNi6esIL8AONs2rGeqqZmHMB dKLEf1dBDZM5pMauxLFWbqNeodbOzg+swSOtkhc= X-Google-Smtp-Source: AOwi7QBeWeSUfZYJvSzVnGjnoMLj82YnFjGXqtsiB5sKYUaVLa2TdB9lPGQ31dN5QQQJCVjZalhwsFc29T2joEwjZeI= X-Received: by 10.25.59.210 with SMTP id d79mr879088lfl.207.1507299322852; Fri, 06 Oct 2017 07:15:22 -0700 (PDT) MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.46.86.77 with HTTP; Fri, 6 Oct 2017 07:15:22 -0700 (PDT) In-Reply-To: References: From: Justin Hibbits Date: Fri, 6 Oct 2017 09:15:22 -0500 X-Google-Sender-Auth: Rl76-jl-ipUwHxndVpiTRsqOQjk Message-ID: Subject: Re: C++ in jemalloc To: Mark Millard Cc: Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:15:25 -0000 Hi Mark, On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote: > Warner Losh imp at bsdimp.com wrote on > Thu Oct 5 21:01:26 UTC 2017 : > >> Starting in FreeBSD 11, arm and powerpc are supported by clang, >> but not super well. For FreeBSD 12, we're getting close for everything >> except sparc64 (whose fate has not yet been finally decided). > > My understanding of the powerpc and powerpc64 status > follows. This is based on my use of head via clang > as much as I can for them. > > For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc : > > lld is far from working last I knew. (I've focused > more on the compilers for testing, using other > linkers and such.) [lldb may be in a similar state > for powerpc64. It does not build for powerpc.] > > clang 5 (and 4) generated code crashes on any thrown > C++ exception. For example: > > #include > > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } > > crashes. > > Luckily most kernel and world code that I actively use > does not throw C++ exceptions in my use. Do you see this problem using libstdc++, et al, from base gcc 4.2.1? Or using libc++? I don't have the time right now to look into it, but if no one else is able to in the next couple months I'll try to make the time when higher priorities are done. > > But devel/kyua is majorly broken by the C++ exception > issue: It makes extensive use of C++ exceptions. In my > view that disqualifies clang as being "close": I view > my activity as a hack until devel/kyua is generally > operable and so available for use in testing. > > clang 5 currently can not build the TARGET_ARCH=powerpc > kernel. (I was able to back in clang 4 days --but the > resultant build failed to execute init fully after > finishing the prior boot activity.) For the 32-bit > context I use gcc 4.2.1 for building the kernel and > clang 5 for building the world, system binutils > in use in both cases. What problem(s) do you see with this? If they're just compile time failures they can be fixed pretty readily. > > I do build the kernel and world for > TARGET_ARCH=powerpc64 via system clang 5. But I > use ports binutils as well in order for this to > finish and work overall. > > > As for more modern devel/powerpc64-xtoolchain-gcc > (so devel/powerpc64-gcc) versions being used to > build the world and kernel for powerpc64 I've never > been able to get lib32 on powerpc64 to work via > such a build: it builds but fails to execute from > dereferencing via an R30 that has an inappropriate > value for the attempt ( lib32/crtbeginS.o code in > _init in /usr/lib32/libc.so.* ). (The clang-based > builds do not have this problem.) It has been a > while since I've done devel/powerpc64-gcc > experiments. > > I'm not aware of a devel/powerpc-xtoolchain-gcc > as an alternative for 32-bit powerpc targeting. There's documentation floating around (on the wiki maybe?) for doing this. I won't check now, but it's not difficult (not trivial, but not difficult). With the proposal to eliminate gcc 4.2.1 from our tree by the end of the year, we need to get everything in place to make a seamless transition, whether it be to external toolchain or to finish up clang for powerpc. I really hope we can finish up clang. Please continue to file bugs with as much detail as necessary to track down and fix the problems--both in FreeBSD and upstream LLVM. - Justin From owner-freebsd-current@freebsd.org Fri Oct 6 16:05:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54CBFE3A943 for ; Fri, 6 Oct 2017 16:05:02 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) (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 17757643EF for ; Fri, 6 Oct 2017 16:05:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-qt0-f172.google.com with SMTP id 6so23191225qtw.3 for ; Fri, 06 Oct 2017 09:05:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=sq894us461aFht4amgOk6N4elVd3m59E+RB256G823o=; b=Vz9PBoYIo0TG5F1ThcOfkol8h7fdl6dKqBYqXrBwyU19l+5KRzarYWphZo0ht2yDWo 3ztOO1xFs8vgqnhynupty625ATEJfRuMLjUrZG7Pbn3qnA4B95p/rNgMEg+M3ap6T/Af 3fNcAQMVVA3YuiSh5qFSAf7p+Yb7pqV5u34AryJgagnPxXjWgHP2FAkmolc5uypLJsT7 ah5Ko1jiNiics9lBIKeVFySjD6YOHrV1SWlAy7C7iLR1JZ2zJ7LJPxazAZ0PdBm9kUYq w12RdOJITNqWaBPO21kshYHdukff7B4nNboH4upiO1xpUadLsSNf4tVqnKJkFxoxlOzW Jpxg== X-Gm-Message-State: AMCzsaXLI246QZA4XR5QnRZHbsLTR5DbiswjsEz/PUJYS0lmKkIiKybS aLeWXbpWGexLmWM6hMJ3v1UPeANB X-Received: by 10.37.196.65 with SMTP id u62mr1979023ybf.124.1507305894749; Fri, 06 Oct 2017 09:04:54 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id n7sm818176ywh.59.2017.10.06.09.04.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 09:04:54 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id 72so1777964itl.5 for ; Fri, 06 Oct 2017 09:04:54 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDqqLBGcFhJxnEvSjjWiWk24Vfn0SOPqXnDyW5+FO6vqzCBZ8N6pLr1PCkNfS4+gQlKouzaFivknWSgp/nCohU= X-Received: by 10.36.84.81 with SMTP id t78mr2870129ita.117.1507305894127; Fri, 06 Oct 2017 09:04:54 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.144.194 with HTTP; Fri, 6 Oct 2017 09:04:53 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Fri, 6 Oct 2017 09:04:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: C++ in jemalloc To: Mark Millard Cc: Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:05:02 -0000 On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote: > Luckily most kernel and world code that I actively use > does not throw C++ exceptions in my use. > > But devel/kyua is majorly broken by the C++ exception > issue: It makes extensive use of C++ exceptions. In my > view that disqualifies clang as being "close": I view > my activity as a hack until devel/kyua is generally > operable and so available for use in testing. I don't think that is a major roadblock; a broken port is a broken port. Kyua is a relatively unimportant one for most users. In this particular case, maybe kyua (a leaf binary) could be built with GCC instead of Clang on any platform with broken C++ exceptions. Best, Conrad From owner-freebsd-current@freebsd.org Fri Oct 6 16:28:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08477E3B086 for ; Fri, 6 Oct 2017 16:28:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 2A47864FFB for ; Fri, 6 Oct 2017 16:28:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9263 invoked from network); 6 Oct 2017 16:28:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Oct 2017 16:28:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 06 Oct 2017 12:28:39 -0400 (EDT) Received: (qmail 26973 invoked from network); 6 Oct 2017 16:28:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Oct 2017 16:28:38 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EDF37EC92AD; Fri, 6 Oct 2017 09:28:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Fri, 6 Oct 2017 09:28:37 -0700 Cc: Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> References: To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:28:42 -0000 On 2017-Oct-6, at 7:15 AM, Justin Hibbits = wrote: > Hi Mark, >=20 > On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard = wrote: >> Warner Losh imp at bsdimp.com wrote on >> Thu Oct 5 21:01:26 UTC 2017 : >>=20 >>> Starting in FreeBSD 11, arm and powerpc are supported by clang, >>> but not super well. For FreeBSD 12, we're getting close for = everything >>> except sparc64 (whose fate has not yet been finally decided). >>=20 >> My understanding of the powerpc and powerpc64 status >> follows. This is based on my use of head via clang >> as much as I can for them. >>=20 >> For TARGET_ARCH=3Dpowerpc64 and TARGET_ARCH=3Dpowerpc : >>=20 >> lld is far from working last I knew. (I've focused >> more on the compilers for testing, using other >> linkers and such.) [lldb may be in a similar state >> for powerpc64. It does not build for powerpc.] >>=20 >> clang 5 (and 4) generated code crashes on any thrown >> C++ exception. For example: >>=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> crashes. >>=20 >> Luckily most kernel and world code that I actively use >> does not throw C++ exceptions in my use. >=20 > Do you see this problem using libstdc++, et al, from base gcc 4.2.1? > Or using libc++? gcc 4.2.1 buildkernel buildworld work fine for anything that I've tried. They are libstdc++ based. I've not tried clang with libstdc++, just libc++. (Note: clang 3.8, 3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals tend to be from the earlier time frame. Many of my submittals for other types of issues have been addressed. ) But my llvm bugzilla submittals for C++ exceptions indicate errors/incompletenesses in the DW_CFA_ generation, such as for scratch register handling. (Warning: I've not been through the details in some time so this is from a vague memory.) 26844 and 26856 are the relevant ones if I remember right. 31590 might be relevant depending on what linunwind is to be used. Be warned that I do not believe Roman Divacky agrees with my interpretation and I'd never studied the exception handling techniques prior to these investigations. Still I think that I was correct about there being problems in the DW_CFA_ sequences generated. For a separate issue llvm 31716 is relevant for .plt and the function descriptor layout. I use Roman Divacky's patch listing in Comment 1. Included below as well. The llvm patches that I have are both from Roman as I remember: Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp = (revision 324071) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp = (working copy) @@ -1178,7 +1178,7 @@ // For SVR4, don't emit a move for the CR spill slot if we = haven't // spilled CRs. if (isSVR4ABI && (PPC::CR2 <=3D Reg && Reg <=3D PPC::CR4) - && !MustSaveCR) + && (!MustSaveCR && isPPC64)) continue; =20 // For 64-bit SVR4 when we have spilled CRs, the spill location Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision = 324071) +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy) @@ -60,7 +60,8 @@ static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> = 48; } =20 PPC64::PPC64() { - PltRel =3D GotRel =3D R_PPC64_GLOB_DAT; + GotRel =3D R_PPC64_GLOB_DAT; + PltRel =3D R_PPC64_JMP_SLOT; RelativeRel =3D R_PPC64_RELATIVE; GotEntrySize =3D 8; GotPltEntrySize =3D 8; > I don't have the time right now to look into it, but if no one else is > able to in the next couple months I'll try to make the time when > higher priorities are done. Are you familiar with what the DQ_CFA_ sequences should be like given the powerpc scratch register usage and the like? >> But devel/kyua is majorly broken by the C++ exception >> issue: It makes extensive use of C++ exceptions. In my >> view that disqualifies clang as being "close": I view >> my activity as a hack until devel/kyua is generally >> operable and so available for use in testing. >>=20 >> clang 5 currently can not build the TARGET_ARCH=3Dpowerpc >> kernel. (I was able to back in clang 4 days --but the >> resultant build failed to execute init fully after >> finishing the prior boot activity.) For the 32-bit >> context I use gcc 4.2.1 for building the kernel and >> clang 5 for building the world, system binutils >> in use in both cases. >=20 > What problem(s) do you see with this? If they're just compile time > failures they can be fixed pretty readily. I submitted FreeBSD bugzilla 221107 for the: R_PPC_PLTREL24 reloc against local symbol failures. This was using system binutils. In a parallel builds it is a race between agp.* vs. aha.* reporting this and stopping the build. >> I do build the kernel and world for >> TARGET_ARCH=3Dpowerpc64 via system clang 5. But I >> use ports binutils as well in order for this to >> finish and work overall. >>=20 >>=20 >> As for more modern devel/powerpc64-xtoolchain-gcc >> (so devel/powerpc64-gcc) versions being used to >> build the world and kernel for powerpc64 I've never >> been able to get lib32 on powerpc64 to work via >> such a build: it builds but fails to execute from >> dereferencing via an R30 that has an inappropriate >> value for the attempt ( lib32/crtbeginS.o code in >> _init in /usr/lib32/libc.so.* ). (The clang-based >> builds do not have this problem.) It has been a >> while since I've done devel/powerpc64-gcc >> experiments. >>=20 >> I'm not aware of a devel/powerpc-xtoolchain-gcc >> as an alternative for 32-bit powerpc targeting. >=20 > There's documentation floating around (on the wiki maybe?) for doing > this. I won't check now, but it's not difficult (not trivial, but not > difficult). With the proposal to eliminate gcc 4.2.1 from our tree by > the end of the year, we need to get everything in place to make a > seamless transition, whether it be to external toolchain or to finish > up clang for powerpc. I really hope we can finish up clang. Please > continue to file bugs with as much detail as necessary to track down > and fix the problems--both in FreeBSD and upstream LLVM. I've never run into instructions for targeting 32-bit powerpc FreeBSD via some gcc vintage/variant. As I remember: When I tried I failed to figure out how to et devel/powerpc64-gcc and related things to produce what was needed. But I've not retried in a long time. My intended primary environment for FreeBSD build activity is to be unavailable for a month or so. So I'm currently limited to slower alternatives. Another amd64 that I otherwise use for cross builds looks like it will have to go out for repair. I did finally get both 32-bit and 64-bit powerpc to jump from well before INO64 to fairly modern recently: head -r324071 . Even the old iMac G3 boots the 32-bit variant. You might want to stop reading here. Details of /usr/src my activity is based on: (some of the below list is not for powerpc families) # svnlite status /usr/src | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/Makefile M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/arm64/arm64/mp_machdep.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c I do have some patches trying to catch a problem that I saw earlier for 32-bit powerpc FreeBSD on old G5 PowerMacs but I've not seen the issue in a long while. I also did something crude to libkvm to get basic raw memory dumps working for that context so I could examine stacks and other things. So some of the powerpc C code files above just have some sort of additional cross check code that is not generally relevant. First I list things more directly tied to building various ways not associated with those cross checks: Index: /usr/src/lib/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 --- /usr/src/lib/Makefile (revision 324071) +++ /usr/src/lib/Makefile (working copy) @@ -158,7 +158,7 @@ .if ${MK_LIBCPLUSPLUS} !=3D "no" _libcxxrt=3D libcxxrt _libcplusplus=3D libc++ -.if ${MACHINE_CPUARCH} !=3D "arm" && ${MACHINE_CPUARCH} !=3D "mips" +.if ${MACHINE_CPUARCH} !=3D "arm" && ${MACHINE_CPUARCH} !=3D "mips" && = ${MACHINE_CPUARCH} !=3D "powerpc" _libcplusplus+=3D libc++experimental .endif .endif Index: /usr/src/sys/boot/ofw/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/ofw/Makefile.inc (revision 324071) +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) @@ -2,7 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 324071) +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) @@ -2,6 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/boot1.chrp/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 --- /usr/src/sys/boot/powerpc/boot1.chrp/Makefile (revision = 324071) +++ /usr/src/sys/boot/powerpc/boot1.chrp/Makefile (working copy) @@ -8,7 +8,7 @@ INSTALLFLAGS=3D -b =20 FILES=3D boot1.hfs -SRCS=3D boot1.c ashldi3.c syncicache.c +SRCS=3D boot1.c qdivrem.c udivdi3.c ashldi3.c syncicache.c =20 MAN=3D =20 Index: /usr/src/sys/boot/powerpc/kboot/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 --- /usr/src/sys/boot/powerpc/kboot/Makefile (revision 324071) +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) @@ -69,8 +69,6 @@ LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a .endif =20 -CFLAGS+=3D -mcpu=3Dpowerpc64 - # Always add MI sources .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern .include "${.CURDIR}/../../common/Makefile.inc" @@ -86,9 +84,6 @@ =20 LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc =20 -# 64-bit bridge extensions -CFLAGS+=3D -Wa,-mppc64bridge - # Pull in common loader code #.PATH: ${.CURDIR}/../../ofw/common #.include "${.CURDIR}/../../ofw/common/Makefile.inc" Index: /usr/src/sys/boot/uboot/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/uboot/Makefile.inc (revision 324071) +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/conf/kmod.mk (revision 324071) +++ /usr/src/sys/conf/kmod.mk (working copy) @@ -151,8 +151,12 @@ .endif =20 .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif =20 .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls Index: /usr/src/sys/powerpc/ofw/ofw_machdep.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 --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 324071) +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -111,26 +111,27 @@ * Assume that interrupt are disabled at this point, or * SPRG1-3 could be trashed */ -#ifdef __powerpc64__ - __asm __volatile("mtsprg1 %0\n\t" - "mtsprg2 %1\n\t" - "mtsprg3 %2\n\t" - : - : "r"(ofmsr[2]), - "r"(ofmsr[3]), - "r"(ofmsr[4])); -#else - __asm __volatile("mfsprg0 %0\n\t" - "mtsprg0 %1\n\t" - "mtsprg1 %2\n\t" - "mtsprg2 %3\n\t" - "mtsprg3 %4\n\t" - : "=3D&r"(ofw_sprg0_save) - : "r"(ofmsr[1]), - "r"(ofmsr[2]), - "r"(ofmsr[3]), - "r"(ofmsr[4])); +#ifndef __powerpc64__ + if (!(cpu_features & PPC_FEATURE_64)) + __asm __volatile("mfsprg0 %0\n\t" + "mtsprg0 %1\n\t" + "mtsprg1 %2\n\t" + "mtsprg2 %3\n\t" + "mtsprg3 %4\n\t" + : "=3D&r"(ofw_sprg0_save) + : "r"(ofmsr[1]), + "r"(ofmsr[2]), + "r"(ofmsr[3]), + "r"(ofmsr[4])); + else #endif + __asm __volatile("mtsprg1 %0\n\t" + "mtsprg2 %1\n\t" + "mtsprg3 %2\n\t" + : + : "r"(ofmsr[2]), + "r"(ofmsr[3]), + "r"(ofmsr[4])); } =20 static __inline void @@ -147,7 +148,8 @@ * PCPU data cannot be used until this routine is called ! */ #ifndef __powerpc64__ - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); + if (!(cpu_features & PPC_FEATURE_64)) + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); #endif } #endif The cross check code is code like the following but should not be important outside my context: +if ((((uintptr_t) frame) & 0x3) !=3D 0x0) { panic("trap: frame = misaligned"); } // HACK +if ((void*) frame < (void*) 0x1000) { panic("trap: frame too = small"); } // HACK and: +if ((((uintptr_t) framep) & 0x3) !=3D 0x0) { panic("powerpc_interrupt: = framep misaligned"); } // HACK +if ((void*) framep < (void*) 0x1000) { panic("powerpc_interrupt: = framep too small"); } // HACK and: avoiding VM_PROT_EXECUTE on most kernel pages with no code (when PPC_FEATURE_64 is present): struct pvo_entry *pvo, *oldpvo; =20 pvo =3D alloc_pvo_entry(0); +#if defined(AIM) && !defined(__powerpc64__) + if (cpu_features & PPC_FEATURE_64) + { + if ( va < ((vm_offset_t)(etext+(PAGE_SIZE-1)) & = ~PAGE_MASK) ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + + else if ( ((vm_offset_t)_GOT_START_ & ~PAGE_MASK) <=3D = va + && va < ((vm_offset_t)(_GOT_END_+(PAGE_SIZE-1)) = & ~PAGE_MASK) + ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + + else if ( va < (__endkernel & ~PAGE_MASK) ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE; + + else // Otherwise do as before the HACK: + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + } + else +#endif pvo->pvo_pte.prot =3D VM_PROT_READ | VM_PROT_WRITE | = VM_PROT_EXECUTE; pvo->pvo_pte.pa =3D (pa & ~ADDR_POFF) | moea64_calc_wimg(pa, = ma); pvo->pvo_vaddr |=3D PVO_WIRED; combined with: Index: /usr/src/sys/conf/ldscript.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/conf/ldscript.powerpc (revision 324071) +++ /usr/src/sys/conf/ldscript.powerpc (working copy) @@ -24,6 +24,9 @@ _etext =3D .; PROVIDE (etext =3D .); =20 + /* Force after this to start on a separate page from what is *before* = _etext/etext */ + . =3D ((. + 0x1000 - 1) & ~(0x1000 - 1)); + .interp : { *(.interp) } .hash : { *(.hash) } .dynsym : { *(.dynsym) } As for the libkvm hacks to get raw memory dumps: Index: /usr/src/lib/libkvm/kvm_powerpc.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 --- /usr/src/lib/libkvm/kvm_powerpc.c (revision 324071) +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy) @@ -209,6 +209,53 @@ if (be32toh(vm->ph->p_paddr) =3D=3D 0xffffffff) return ((int)powerpc_va2off(kd, va, ofs)); =20 + // HACK in something for what I observe in + // a debug.minidump=3D0 vmcore.* for 32-bit powerpc + // + if ( be32toh(vm->ph->p_vaddr) =3D=3D 0xffffffff + && be32toh(vm->ph->p_paddr) =3D=3D 0 + && be16toh(vm->eh->e_phnum) =3D=3D 1 + ) { + // Presumes p_memsz is either unsigned + // 32-bit or is 64-bit, same for va . + + if (be32toh(vm->ph->p_memsz) <=3D va) + return 0; // Like powerpc_va2off + + // If ofs was (signed) 32-bit there + // would be a problem for sufficiently + // large postive memsz's and va's + // near the end --because of p_offset + // and dmphdrsz causing overflow/wrapping + // for some large va values. + // Presumes 64-bit ofs for such cases. + // Also presumes dmphdrsz+p_offset + // is non-negative so that small + // non-negative va values have no + // problems with ofs going negative. + + *ofs =3D vm->dmphdrsz + + be32toh(vm->ph->p_offset) + + va; + + // The normal return value overflows/wraps + // for p_memsz =3D=3D 0x80000000u when va =3D=3D 0 . + // Avoid this by depending on calling code's + // loop for sufficiently large cases. + // This code presumes p_memsz/2 <=3D MAX_INT . + // 32-bit powerpc FreeBSD does not allow + // using more than 2 GiBytes of RAM but + // does allow using 2 GiBytes on 64-bit + // hardware. + // + if ( (int)be32toh(vm->ph->p_memsz) < 0 + && va < be32toh(vm->ph->p_memsz)/2 + ) + return be32toh(vm->ph->p_memsz)/2; + + return be32toh(vm->ph->p_memsz) - va; + } + _kvm_err(kd, kd->program, "Raw corefile not supported"); return (0); } Index: /usr/src/lib/libkvm/kvm_private.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 --- /usr/src/lib/libkvm/kvm_private.c (revision 324071) +++ /usr/src/lib/libkvm/kvm_private.c (working copy) @@ -128,7 +128,9 @@ { =20 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && - kd->nlehdr.e_type =3D=3D ET_EXEC && + ( kd->nlehdr.e_type =3D=3D ET_EXEC || + kd->nlehdr.e_type =3D=3D ET_DYN + ) && kd->nlehdr.e_machine =3D=3D machine); } =20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Oct 6 16:29:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A40C5E3B10F for ; Fri, 6 Oct 2017 16:29:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 67CFB6512E for ; Fri, 6 Oct 2017 16:29:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id y15so1778771ita.4 for ; Fri, 06 Oct 2017 09:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c3xOeWv6zcYAloNfAD7zWUBQg51VxYHdSxHsG0DeRGA=; b=f7JR8E+vWot2Z1VwCYUQOnsj1OVqUinsUo8p9C1ELIIHp3LaebAjPoGBY30QmnYKT3 pYmMPzFsijOkFu+5dIZin/1e9tR28jXMRbHRNP7YDWYe0cH6Hd44llP/lD3SlvvPH0Ac aOiuG4y/lUV6zjJIp96ElVP5kNXD7sWPioovT4gM62gdSOl3Ovj8lEDU7PtVJUPkT5JI 2xzUUEqyy/7aWbx3Z7zcFHqLejAOyK7qFSOFrPaVv/uLc7TFzzqQQT4gZ9c+YliVVTPz 56WLJR5p8oyBSusWx4KbBWDE7hOqrQZXMk6y32Hdyd7K31Itu0FuxzwDKMs1OQ5brBlC ffoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c3xOeWv6zcYAloNfAD7zWUBQg51VxYHdSxHsG0DeRGA=; b=VV4vTG6k5o0yE5XNBdBPVAL/IIQJTN3adJsxokUASnxvFo5ZqBOdDh4mBQs+4A4HQP KYyaKib040E2YoLXIyVYZof1SfV+Go2suwgsuozRl7bnnBg0w2haHDXvIJ3cXUUVIjeB cvU8lsgWcRwfqCwRC4oNN/movuawHT17by8ExSTIY4O+l3FnAxXtWdp3i2tRH4ULvfKm YLH6b42bk/1LE2729VTcWHJ1/OGL/maoOrhh9V555TBGaogrG8BJFH9c7AEC/PZvpmBv xzNZuPHdn8w3hgCmD2ELlrBpyBuH7iFSuX/NPRonRAjOkL+77EDVZ0eMtfQrr8PRwYxt I68g== X-Gm-Message-State: AMCzsaVtozRPXpk/pvSwPPTC2LuoHDNvspud2J2sGzx2Z1QBBpgEal8b kYkL2AUrxMGZU+gVytrYTHHMneJhJfgEBiIMBcJI4Q== X-Google-Smtp-Source: AOwi7QDcaRNONp2C+jX79Ra9kmNxt3vEkiabTwOe+Vy6p0A25nubkC8pZwf+9K/F+07Lz5DfMptSs7TdwMOI/6kEkkA= X-Received: by 10.36.19.207 with SMTP id 198mr3003936itz.130.1507307348386; Fri, 06 Oct 2017 09:29:08 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Fri, 6 Oct 2017 09:29:07 -0700 (PDT) X-Originating-IP: [192.173.66.161] In-Reply-To: <1507306665.86205.257.camel@freebsd.org> References: <1507306665.86205.257.camel@freebsd.org> From: Warner Losh Date: Fri, 6 Oct 2017 09:29:07 -0700 X-Google-Sender-Auth: T3F0oR-kWvaPGbhD3hOm_UOPDzM Message-ID: Subject: Re: C++ in jemalloc To: Ian Lepore Cc: "Conrad E. Meyer" , Mark Millard , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:29:10 -0000 On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > > wrote: > > > > > > Luckily most kernel and world code that I actively use > > > does not throw C++ exceptions in my use. > > > > > > But devel/kyua is majorly broken by the C++ exception > > > issue: It makes extensive use of C++ exceptions. In my > > > view that disqualifies clang as being "close": I view > > > my activity as a hack until devel/kyua is generally > > > operable and so available for use in testing. > > I don't think that is a major roadblock; a broken port is a broken > > port. Kyua is a relatively unimportant one for most users. In this > > particular case, maybe kyua (a leaf binary) could be built with GCC > > instead of Clang on any platform with broken C++ exceptions. > > > > Best, > > Conrad > > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. > I'm with Ian: Broken C++ exceptions means a broken C++ compiler. It's best to think of it like the tertiary operator being wonky in 'C'... Warner From owner-freebsd-current@freebsd.org Fri Oct 6 16:54:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 764B0E3BAE6 for ; Fri, 6 Oct 2017 16:54:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from cow.apple.relay.mailchannels.net (cow.apple.relay.mailchannels.net [23.83.208.41]) (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 352A16615C for ; Fri, 6 Oct 2017 16:54:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6C11369155 for ; Fri, 6 Oct 2017 16:17:57 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.140.232]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 2742F368FA4 for ; Fri, 6 Oct 2017 16:17:56 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.110.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Fri, 06 Oct 2017 16:17:57 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Vacuous-Callous: 355dab2c6333e45f_1507306677543_3500172096 X-MC-Loop-Signature: 1507306677543:1363086923 X-MC-Ingress-Time: 1507306677542 X-MHO-User: e49e070c-aab1-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e49e070c-aab1-11e7-a893-25625093991c; Fri, 06 Oct 2017 16:17:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v96GHjpl006240; Fri, 6 Oct 2017 10:17:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507306665.86205.257.camel@freebsd.org> Subject: Re: C++ in jemalloc From: Ian Lepore To: cem@freebsd.org, Mark Millard Cc: Warner Losh , FreeBSD Current Date: Fri, 06 Oct 2017 10:17:45 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:54:43 -0000 On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > wrote: > > > > Luckily most kernel and world code that I actively use > > does not throw C++ exceptions in my use. > > > > But devel/kyua is majorly broken by the C++ exception > > issue: It makes extensive use of C++ exceptions. In my > > view that disqualifies clang as being "close": I view > > my activity as a hack until devel/kyua is generally > > operable and so available for use in testing. > I don't think that is a major roadblock; a broken port is a broken > port.  Kyua is a relatively unimportant one for most users.  In this > particular case, maybe kyua (a leaf binary) could be built with GCC > instead of Clang on any platform with broken C++ exceptions. > > Best, > Conrad It isn't about "a broken port".  All C++ code is broken if exceptions don't work.  That means devd is broken.  Not to mention clang itself.  It may be that neither of those relies on exceptions for routine operation and uses them only for error handling, and errors mostly don't happen.  There is plenty of C++ code in the world where exceptions are used in non-fatal-error cases and where the applications just don't work at all without them. -- Ian From owner-freebsd-current@freebsd.org Fri Oct 6 16:59:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 820ADE3BD00 for ; Fri, 6 Oct 2017 16:59:05 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com [209.85.216.170]) (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 4509F66517; Fri, 6 Oct 2017 16:59:04 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-qt0-f170.google.com with SMTP id q4so32586268qtq.8; Fri, 06 Oct 2017 09:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ykPquWqivZoQXRbmwlLy9XMeyTJTrETTA5+L3QYm18I=; b=mQaXlWnL4DjYQilUSnt6mA5iIJ6dI5pdeYhbCUnE4tW7PVaR6anWQsZH1VyUNpTdeJ 61wlBQS79LnkwwjlJqY3dOF2OF+eN1tIVOGhS5ZLk+hdp9btwjG0DREmYmndRO20PgA5 TNupNyyvQhkIdLmQuMyXhxWcKk3zPn31GDywLaG7103DsiObMGh077Jw6mYr2yxrtR2c t+1KydPWShQCrzyxZBXh9hPfeb0tpbm7nw9c3/q1dsj/UqGcX7PH15u4/4hqbinpfQ3h h7xDXCe6IFZ7burlerTT1VYfI8pgPUVvtG6AQJAn0kpRX80nbMHLYcMN05S/uLtiXNir LFnQ== X-Gm-Message-State: AMCzsaUi+w5ORnmS0sz7J/dcPvGQ32oHFaflQtZte8Rtrk5zueTH1ZtM Gz7eU0hxWIBSCp8fo6qjPoLt2rOr X-Received: by 10.37.47.205 with SMTP id v196mr2038064ybv.325.1507309137794; Fri, 06 Oct 2017 09:58:57 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id s38sm1855166ywa.92.2017.10.06.09.58.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 09:58:57 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id y15so1885755ita.4; Fri, 06 Oct 2017 09:58:57 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDt+7KPdHrsRD6QF1OrTvWoQp1Zvent6hWStjSBjcRprI82o6taLDqiTpgn4ct8k7vM13BJilLpodtGZ0Hu4b0= X-Received: by 10.36.154.66 with SMTP id l63mr3267222ite.118.1507309137161; Fri, 06 Oct 2017 09:58:57 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.144.194 with HTTP; Fri, 6 Oct 2017 09:58:56 -0700 (PDT) In-Reply-To: <1507306665.86205.257.camel@freebsd.org> References: <1507306665.86205.257.camel@freebsd.org> From: Conrad Meyer Date: Fri, 6 Oct 2017 09:58:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: C++ in jemalloc To: Ian Lepore Cc: Mark Millard , Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:59:05 -0000 On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. Then use G++ for C++ on those second-tier architectures. We've got a working C++ toolchain. Conrad From owner-freebsd-current@freebsd.org Fri Oct 6 17:04:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46749E3C1FD for ; Fri, 6 Oct 2017 17:04:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 E0E0566A3D for ; Fri, 6 Oct 2017 17:04:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9856 invoked from network); 6 Oct 2017 17:04:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Oct 2017 17:04:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 06 Oct 2017 13:04:31 -0400 (EDT) Received: (qmail 31760 invoked from network); 6 Oct 2017 17:04:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Oct 2017 17:04:31 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 05A1CEC809E; Fri, 6 Oct 2017 10:04:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Fri, 6 Oct 2017 10:04:30 -0700 Cc: Ian Lepore , Warner Losh , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <1806F8FF-D0EA-42A2-BA72-85975EAD808F@dsl-only.net> References: <1507306665.86205.257.camel@freebsd.org> To: cem@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:04:34 -0000 On 2017-Oct-6, at 9:58 AM, Conrad Meyer wrote: > On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: >> It isn't about "a broken port". All C++ code is broken if exceptions >> don't work. That means devd is broken. Not to mention clang itself. >> It may be that neither of those relies on exceptions for routine >> operation and uses them only for error handling, and errors mostly >> don't happen. There is plenty of C++ code in the world where >> exceptions are used in non-fatal-error cases and where the applications >> just don't work at all without them. > > Then use G++ for C++ on those second-tier architectures. We've got a > working C++ toolchain. g++'s toolchain (such as via devel/powerpc64-xtoolchain-gcc ) has its own problems: A) For targeting powerpc64 it fails to build a working lib32. (This may well be better than clang's status overall.) B) For targeting powerpc (32-bit): what toolchain? === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Oct 6 19:02:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A89CE3ED88 for ; Fri, 6 Oct 2017 19:02:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0085.outbound.protection.outlook.com [104.47.37.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3391D6B5FE for ; Fri, 6 Oct 2017 19:02:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB2101.CANPRD01.PROD.OUTLOOK.COM (52.132.77.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 6 Oct 2017 19:02:48 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Fri, 6 Oct 2017 19:02:48 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: RFC how to use kernel procs/threads efficiently Thread-Topic: RFC how to use kernel procs/threads efficiently Thread-Index: AQHTPtSLQYujf8n5KEGHc2bjAF54kg== Date: Fri, 6 Oct 2017 19:02:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB2101; 6:/6PHd1Uwbt0gf3k7wsPx34sKmltxV5wH1DGKq75upgaeo3wq6N6gV0ltAL9QbIEjWQI/cAu1/Xlu7buynpAMK0vYoSeWCW06O+LMHVaE/NV02DpdjPgLIvlGJjqTnJz4uA6IGXitdFqbNTa3FMb5FMTkLxntBV0aKcWOXvGY/9fuQQI/uS3webeY+rbbWWu9OnPgA1n8ol+X67hFYa3xsYzFwX9d5R134xx7OZ8isa2NwxUxxEjfVcYFo6gHqkvJGQfyV3hdc+sB/gVVPNjjes0tJfSmqa+nrXZ+D+DHD3Jw8Ac07tQccSCQzDHWJDFrRpH2marx79B1Qjev1fjDDg==; 5:ApmVwg0ZaK/N1gESgwXVF7vOhi7Q6fkOP/zYhkqckoUJYGgCsDwyB7Ua61vdwR4RL1zd9jdndoht2k2YpvBNcprqwcigx45ldwA3TTwGJOWZQwtOmtXJGsnnv+ifEHklT2cmotrcKJKgBR9bXmgmjA==; 24:eSWDH0FIbT9smvfAsvOjbYAWrFx+LfDBdLhYJfPnnZs2j/bWAc7ftu1jSCDCaLkkYBkYyD0TwFUZK7iTVn5WM27kqUNVP2ZvhMub2fo2cTY=; 7:LnQmv+u7EbG3U6q+F7hWnWVNLXVSEwNRJlUXwYS8x0Qy4NrxNPHXVfnr7UoRxdY/PUdO1de0XecFI8zIE3JlOQdLUO13yAes+Z0/SDxAmI0Z0N0h3XXGBx5kgPPpVyBgvoL/gQtquXa6sIcQ3gtvUmJb1X3P3MjSHqIUOML1mMMZBcetVdb5U20MjJimHFa8bqc7HPMGNlacwZeKeyDnqMkqmp3fT5DBQtbJ2UEMx7M= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6a1c896c-b30a-4c60-2427-08d50cecd623 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB2101; x-ms-traffictypediagnostic: YQXPR0101MB2101: x-exchange-antispam-report-test: UriScan:(158342451672863)(5213294742642); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB2101; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB2101; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(97736004)(86362001)(105586002)(53936002)(9686003)(101416001)(3280700002)(50986999)(7696004)(5250100002)(33656002)(81156014)(14454004)(54356999)(81166006)(8936002)(478600001)(2900100001)(189998001)(786003)(74316002)(2906002)(2501003)(25786009)(305945005)(8676002)(68736007)(5640700003)(2351001)(3660700001)(6436002)(106356001)(102836003)(6916009)(316002)(55016002)(6506006)(74482002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB2101; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 19:02:48.5516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB2101 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 19:02:51 -0000 Hi, I have now dropped the client side of Flexible File Layout for pNFS into he= ad and I believe it is basically working. Currently when talking to mirrored DS servers, it does the Write and Commit RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed= to to completion. To do them concurrently, I need separate kernel processes/threads to do the= m. I can think of two ways to do this: 1 - The code that I have running in projects/pnfs-planb-server for the pNFS= server side does a kproc_create() to create a kernel process that does the R= PC and then krpc_exit()s. - This was easy to code and works. However, I am concerned that there= is going to be excessive overheads from doing all the kproc_create()s = and kproc_exit()s? Anyone know if these calls will result in large overheads? 2 - I haven't coded this, but the other way I can think of to do this is to create a pool of threads (kthread_create() is sufficient in this case= , I think?) and then hand each RPC to an available thread so it can do th= e RPC. - Other than a little more complex coding, the main issue I see with = this one is "How many threads and when to create more/less of them.". Anyhow, any comments w.r.t. the merits of either of the above approaches (or a suggestion of other ways to do this) would be appreciated, rick= From owner-freebsd-current@freebsd.org Fri Oct 6 19:11:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EEBCE3F071 for ; Fri, 6 Oct 2017 19:11:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 5304A6BAF8 for ; Fri, 6 Oct 2017 19:11:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1c9b575f-aaca-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1c9b575f-aaca-11e7-a937-4f970e858fdb; Fri, 06 Oct 2017 19:11:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v96JB0KQ006513; Fri, 6 Oct 2017 13:11:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507317060.86205.268.camel@freebsd.org> Subject: Re: RFC how to use kernel procs/threads efficiently From: Ian Lepore To: Rick Macklem , "freebsd-current@freebsd.org" Date: Fri, 06 Oct 2017 13:11:00 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 19:11:03 -0000 On Fri, 2017-10-06 at 19:02 +0000, Rick Macklem wrote: > Hi, > > I have now dropped the client side of Flexible File Layout for pNFS into head > and I believe it is basically working. > Currently when talking to mirrored DS servers, it does the Write and Commit > RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed to to > completion. > > To do them concurrently, I need separate kernel processes/threads to do them. > I can think of two ways to do this: > 1 - The code that I have running in projects/pnfs-planb-server for the pNFS server >       side does a kproc_create() to create a kernel process that does the RPC and >       then krpc_exit()s. >       - This was easy to code and works. However, I am concerned that there is >         going to be excessive overheads from doing all the kproc_create()s and >         kproc_exit()s? >        Anyone know if these calls will result in large overheads? > 2 - I haven't coded this, but the other way I can think of to do this is to >       create a pool of threads (kthread_create() is sufficient in this case, I >       think?) and then hand each RPC to an available thread so it can do the RPC. >       - Other than a little more complex coding, the main issue I see with this one >         is "How many threads and when to create more/less of them.". > > Anyhow, any comments w.r.t. the merits of either of the above approaches > (or a suggestion of other ways to do this) would be appreciated, rick taskqueue(9) is an existing mechanism to enqueue functions to execute asynch using a pool of threads, but it doesn't answer the scalability questions.  In fact it may make them harder, inasmuch as I don't think there's a mechanism to dynamically adjust the number of threads after first calling taskqueue_start_threads(). -- Ian From owner-freebsd-current@freebsd.org Fri Oct 6 19:47:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A457EE40336 for ; Fri, 6 Oct 2017 19:47:14 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E9BA6D77F for ; Fri, 6 Oct 2017 19:47:13 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.85.189]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgptO-1dTzB81Bhe-00oJn9; Fri, 06 Oct 2017 21:47:04 +0200 Date: Fri, 6 Oct 2017 21:46:57 +0200 From: "O. Hartmann" To: Warner Losh Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: r324353: boot failure: failed with error 19 Message-ID: <20171006214657.3dc4f2f6@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/WuK_BzX0dMrO9H.2caqcyA3"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:atk3V5Gkk1VHRuwMit42siXRw2eKHVXgG9nD9W7heq6frcbD9DE PhMTazDVtjEn0iAF2wPDVHL24xQLDRokrWyrpgBWbrizHHDeYDaAK0REkgdaqfNzT94Ca27 Wj4vvI+mBmofVoY7dBwdglxpbZQe2Df4xXRoXoVg1yBKtnZdYehiXdReyA7HoUb0irzHDDy 41ot80MKl2h1e8ZcR1bDA== X-UI-Out-Filterresults: notjunk:1;V01:K0:RxhqKX8tsmk=:77SB/3es2jjvyN14I7ZdDp Nu3VNEihPyKOfPKmO8X+9zNMOsUTzU0tmbfo1Or5d0O8zHfgVL+WZt3Qxjq64jsHJyF7Pv68F aiKMr99NdDcvZGiZqBgpFlG2Bogo3xJ1bnufcQ4vC8TeSQBOmEfYW6sa17dmFdqEc5QAbYbyw CiGTldNACfWYOkzF/s1xHnYceLZWIJmTTF6ZNSP1dfzhL9bCxDt3tJxzmZ85GNhFHH+sNzJQF iAyx+1y+gelT5AurbkBgXOCioEAbEKtY4x8slnLQ1MiYAgMkM+i2XHOCmlqJAPsNEjeB04ivB UI5NrQZoSdCuBkAxDstkBiG0geYHCx9ZKK2u9XI1Fs5rqQap5ufkADCA3T6HPcVh38vASShcQ +Qck2sSdppEpmmSI2W1MR7Zj1bL6Z1qtmBT90UwzW/2rN9Lav3BBFf2TSCuupZYCQ+JzULYwO xJmG1uOi7I5zcS3kflyMyI/S9RgNi/upHqva9pyNgoMtjMMOMxfLTADwBcswcbzBtYyw69J+b fEsrmhfWFo9HGXsicgGvi3P4YMeLYw6F4bwGLf2dSa4BTg8LCer58cAzpHAvwp4TO/pQRz8Y5 M6JuQWmP7JMWH/Bj2chehIU3bmJRA672A6DyxpuF/Ao+WJ+t5GL8Qy7fdZshUr/nweZIxLgxu jKD/+Ww0UpBZhAYD0l8CFLqkiWSYEdkj5i6+IfTxCR+SqAkSWYq1r8NPjaFuvNugZfYDgEnMI K24+n5D3XgkD05gAPEt1aETuTLiDMmYobgjbvyCAGqPKd3kBZQ2cZ9OFwpD8ohJ0cLnO9jgji tMLK+kUlefVgWiuRFLvHZkYzbfiAA== X-Mailman-Approved-At: Fri, 06 Oct 2017 20:14:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 19:47:14 -0000 --Sig_/WuK_BzX0dMrO9H.2caqcyA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Fri, 6 Oct 2017 07:10:44 -0700 Warner Losh schrieb: > On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrot= e: >=20 > > I run a small appliance on an APU from PCengines. This box is bootet via > > SD card, the > > image is created by a modified NanoBSD, which creates GPT/UEFI > > partitioning and booting > > images. > > > > That worked until two days ago (I do not track the revision numer) when= I > > wrote (via dd) > > the last image out. Today, I tried to boot r324353 and it fails at tthe > > boot loader: > > > > > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > =20 >=20 > That's odd... But likely a race.... It could be that dd'ing the new > partition, however, was made from an image that didn't have the proper ufs > label. The images I write out seem to have the correct /dev/gpt/ entries, but the = /dev/ufs entries are missing. Writing labels with glabel produces entries in /dev/l= abel/, but I still miss those in /dev/ufs/. This is more than confusing. >=20 > What's the rev of the last version that worked? As I wrote before, I do not track and since the image has been overwritten,= I do not know. But it isn't older than two days. >=20 > Warner >=20 >=20 > > I can proceed by manually issuing at the loader propmpt > > > > ufs:/dev/gpt/dsks1a > > > > and booting proceeds as expected. > > > > > > Something seems wrong with the UFS labeling lately. > > > > The gpt layout looks like this: > > > > gpart show -l: > > =20 > > =3D> 40 60751792 mmcsd0 GPT (29G) =20 > > 40 130 1 boot (65K) > > 170 6 - free - (3.0K) > > 176 2057288 2 dsks1a [bootme] (1.0G) > > 2057464 2061725 3 dsks2a (1.0G) > > 4119189 1048576 4 dsks3 (512M) > > 5167765 55584067 - free - (27G) > > > > From dmesg. I can provide this last output: > > > > [...] > > mmcsd0: 31GB at mmc0 > > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a > > [ro]... > > uhub0: 4 ports with 4 removable, self powered > > Root mount waiting for: usbus1 > > uhub1: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus1 > > ugen1.2: at usbus1 > > uhub2 on uhub1 > > uhub2: = on > > usbus1 > > uhub2: 4 ports with 4 removable, self powered > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/ufs/dsks1a > > vfs.root.mountfrom.options=3Dro > > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:tank > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > =20 > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\= ^[[Cs =20 > > []... > > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > > random: unblocking device. > > arc4random: no preloaded entropy cache > > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error > > 19. > > =20 > > mountroot> Invalid file system specification. =20 > > =20 > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... =20 > > arc4random: no preloaded entropy cache > > GEOM_ELI: Device gpt/swap.eli created. > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: hardware > > Link state changed to up > > > > [...] > > > > > > Can someone look into this? > > > > Kind regards, > > > > Oliver > > -- > > O. Hartmann > > > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3= =BCr > > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 = Abs. 4 BDSG). > > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/WuK_BzX0dMrO9H.2caqcyA3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdfdsQAKCRDS528fyFhY lMrWAf9KVGonelLTvdGfisZImVWncva9GmvTbNvPjd39o+JUkVeaP+iEt32KIBi1 s7G6TinCezT2J8qTWC0fcXVLg3G8Af9l37KUlASxRAPdU7Ijo0ZO2sYo3PQ4Tyy8 ElIC8Sku0Ro2er4QScczWIsKw0Pejwkk+M8lfwHVWlVFn3Nrxd+8 =qzwk -----END PGP SIGNATURE----- --Sig_/WuK_BzX0dMrO9H.2caqcyA3-- From owner-freebsd-current@freebsd.org Fri Oct 6 20:35:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56E37E412BB for ; Fri, 6 Oct 2017 20:35:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8F5B6EEFC for ; Fri, 6 Oct 2017 20:35:06 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.90.251]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LdYdG-1dZRyJ3rn8-00inSi; Fri, 06 Oct 2017 22:33:34 +0200 Date: Fri, 6 Oct 2017 22:33:01 +0200 From: "O. Hartmann" To: Trond =?ISO-8859-1?Q?Endrest=F8l?= Cc: "O. Hartmann" , FreeBSD CURRENT , Warner Losh Subject: Re: r324353: boot failure: failed with error 19 Message-ID: <20171006223214.580eb09c@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/hneFoi0X9NH0+veIBqaGqvL"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:3olNJUFhelRb/tyMplPn6V39qV71fJG2Q3WIHB9eDpgqb92+NQg Hj4RGatWu1Pf22p2bhXNwj9z0WEc2JDHyqsw4G/TX6VBHLOd1rRX3Av7IFtFIw5E41mBlVg BWPpLcM0d3M5mOH2Xf5ldcfclaFI/cS1kGMFBaesB966ACVwQRSIxImqfKRxX8ofHtzXAeJ bjKWq84qlBeF6QO/awZ3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:FqlK288F1j0=:7sZ/OSRN3lQUNqB+wwMbb/ Ut+tbqeZ3kw5ARSvtY3mLJLYT8cMjijO0GrwKbFb+grHlK+EH8XNF4Sv3vP1PpOacoFwRGzty MvEGi0Fg3FaocMdMvngZT/ea0HFLd5WgDV9uXNksDBnfHHyMNYPh/bgpR+5PmRg2xtzlIPv/2 mdm7F8yl7tj8EkGsFQUdrNUyZpotQXz8oYdVroKLqw8NzO6+zW1KD+9AjSa7WgJx7PQXv49rN 8Fs8JrPudGAUhorQ47iYC1f6McnpqKHm3AkUfZarAstp87YYIzi8TVCpguxObedUjrA4U/2Y2 yuIdjN9eWs4HCuPv7hK/HU8h79UtgpauKF6UrMBA7EPveUlvG5q2scvEX69p+E/ufZOLB+T9M y5JjAJE1227pDQCod9AU03x3/1+wMjf9DKHhJk0n/t2xhTJDfiA4kCwn6KFPT0uOkvw7SNo5D 8anRVUwtfKQda16HmgDpPCyIUiu92YLn/ARSydLmLaD/PwrSTdZ1QmsjzARrWnJryD8YgN5qF quKhwtPMkvKjcrwrJjnYd4vCbUcst2okFsIVNMKxNNbIKadKkSl8TUdCkYEaDnjx8MfOBMCaP xddtcWnrjAz5aQIiXSXkaPYlGLRiljSDmbbi6uyzZPbS3qV1D94Z87wlVRzpwfdOFz4PxnozR xfwkh8l2JhteSf1PB1A29Ii8SZc5PkCHa0t9mJPZjqOFoHj2l/VCxHcLkWR7PQsexmphYBuj+ /QN0vTDYSRIGDQMhHfTE9hCyBbDrDMr13Yul17mGJF4EQ5lBiSW+Fu5iUA8dhQkQRH0VnE1ZV a+HeScVT1nrFTbF96LTtgnn5oizAQ== X-Mailman-Approved-At: Fri, 06 Oct 2017 23:23:34 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:35:07 -0000 --Sig_/hneFoi0X9NH0+veIBqaGqvL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST) Trond Endrest=C3=B8l schrieb: > On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: >=20 > > I run a small appliance on an APU from PCengines. This box is bootet vi= a SD card, the > > image is created by a modified NanoBSD, which creates GPT/UEFI partitio= ning and > > booting images. > >=20 > > That worked until two days ago (I do not track the revision numer) when= I wrote (via > > dd) the last image out. Today, I tried to boot r324353 and it fails at = tthe boot > > loader: > >=20 > >=20 > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > >=20 > >=20 > > I can proceed by manually issuing at the loader propmpt > >=20 > > ufs:/dev/gpt/dsks1a > >=20 > > and booting proceeds as expected. =20 > >=20 > >=20 > > Something seems wrong with the UFS labeling lately. > > =20 >=20 > > The gpt layout looks like this: > >=20 > > gpart show -l: > > =20 > > =3D> 40 60751792 mmcsd0 GPT (29G) =20 > > 40 130 1 boot (65K) > > 170 6 - free - (3.0K) > > 176 2057288 2 dsks1a [bootme] (1.0G) > > 2057464 2061725 3 dsks2a (1.0G) > > 4119189 1048576 4 dsks3 (512M) > > 5167765 55584067 - free - (27G) =20 >=20 > For one, these are the GPT labels. >=20 > Can you verify the UFS labels (volnames)? >=20 > Try: dumpfs /dev/gpt/dsks1a >=20 > > From dmesg. I can provide this last output: > >=20 > > [...] > > mmcsd0: 31GB at mmc0 > > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a = [ro]... > > uhub0: 4 ports with 4 removable, self powered > > Root mount waiting for: usbus1 > > uhub1: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus1 > > ugen1.2: at usbus1 > > uhub2 on uhub1 > > uhub2: = on usbus1 > > uhub2: 4 ports with 4 removable, self powered > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > >=20 > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/ufs/dsks1a > > vfs.root.mountfrom.options=3Dro > >=20 > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > >=20 > > eg. ufs:/dev/da0s1a > > zfs:tank > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > >=20 > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > =20 > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\= ^[[Cs []... =20 > > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > > random: unblocking device. > > arc4random: no preloaded entropy cache =20 >=20 > > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error= 19. =20 This is because me stupid hit the backspace key in the boot loader console = :-( >=20 > This surely indicates a mangled UFS volname. >=20 > Maybe you should rewrite the volname: >=20 > tunefs -L dsk1a /dev/gpt/dsks1a NanoBSD, the original one, defines a "NANO_DRIVE", which is the expansion of /ufs/"NANO_LABEL". When creating the memory backed filesystem via gpart,= the label is given by the option "-l ${NANO_LABEL}${NANO_CFG_LBL}". NANO_LABEL is set to= "dsk". NANO_CFG_LBL is an extension of my own - I needed for a project GPT/UEFI bo= oting NanoBSD images and I wanted to stay compatible with the code given by Kamp et al., = so NANO_CFG_LBL is set to s3. This should then provide the fstab entry "/dev/u= fs/dsks3" for the cfg partition. Accordingly, the primary boot partition has "/dev/ufs/ds= ks1a". It is a bit messy, since I was in a hurry and had to deal with this crappy MBR slic= e style s1a through s1h. This is what I setup in "defaults-add.sh", just to give the impression, wha= t I intended to do: [...] # Set NANO_LABEL to non-blank to form the basis for using /dev/ufs/label # in preference to /dev/${NANO_DRIVE} # Root partition will be ${NANO_LABEL}s{1,2} # /cfg partition will be ${NANO_LABEL}s3 # /data partition will be ${NANO_LABEL}s4 : ${NANO_LABEL=3D"dsk"} # # Labels for the boot and EFI boot partitions : ${NANO_BOOT_LBL=3D"boot0"} : ${NANO_EFI_LBL=3D"efiboot0"} # # Label extensions: form, i.e., ${NANO_LABEL}${NANO_ROOT_LBL} : ${NANO_ROOT_LBL=3D"s1a"} : ${NANO_ALTROOT_LBL=3D"s2a"} : ${NANO_CFG_LBL=3D"s3"} : ${NANO_DATA_LBL=3D"s4"} # : ${NANO_SLICE_ROOT=3D"s1"} : ${NANO_SLICE_ALTROOT=3D"s2"} : ${NANO_SLICE_CFG=3D"s3"} : ${NANO_SLICE_DATA=3D"s4"} [...] The file "defaults-add.sh" is read by "nanobsd.sh" before "defaults.sh" is = read. In "defaults.sh" I altered also all initially set variables to be of the form= =20 ": $VARIABLE=3DSetting}" so my own settings aren't overwritten by accident = and later, when the driver script of nanobsd is setup, one can set his own variables like VARIABLE=3DSetting to overwrite the initial settings. The above should give= in case of a vacant NANO_LABEL the device (like da0) with the propper slice settings - in case of ancient MBR usage. I use then a switch, NANO_GPT. In case its true, NANO_SLICE_XXX is then har= dcoded set to p1 - p4. If NANO_LABEL is vacant First of all, I think something has changed, since /dev/ufs doesn't get pop= ulated anymore by usage of "gpart label" command. Second, there is a high chance that I me= ssed up NanoBSD a bit, a couple of days ago I tried to sync with the code base chan= ges and I made most changes effectively what is now "legacy.sh".=20 >=20 > Or is the volname misspelled? >=20 > tunefs -L dsks1a /dev/gpt/dsks1a >=20 > Or is /etc/fstab on the SD card corrupted? >=20 > > mountroot> Invalid file system specification. =20 > > =20 > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... =20 > > arc4random: no preloaded entropy cache > > GEOM_ELI: Device gpt/swap.eli created. > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: hardware > > Link state changed to up > >=20 > > [...] > >=20 > >=20 > > Can someone look into this? > >=20 > > Kind regards, > >=20 > > Oliver =20 >=20 --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/hneFoi0X9NH0+veIBqaGqvL Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdfofQAKCRDS528fyFhY lA84Af9nL+w0lhqjNiceKFypjh9QpBtsxm8x/Mw46H6E7rJhZehbACjz1eGYcq+b Zno0XKD3N1mvC2TBRQW21qfSY0IIAf9lhIbzBzZC1jSN+Xr2A+XP1NsYt7lq5rTO Nu30B7ZKZjFc+ubqbG/do4VXyApuLP2N0Xbz0qBLkRMvw3Bpwt7x =hbAw -----END PGP SIGNATURE----- --Sig_/hneFoi0X9NH0+veIBqaGqvL-- From owner-freebsd-current@freebsd.org Sat Oct 7 00:45:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 581DFE246B6 for ; Sat, 7 Oct 2017 00:45:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 E23CC75F01 for ; Sat, 7 Oct 2017 00:45:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b4e78a58-aaf8-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id b4e78a58-aaf8-11e7-a893-25625093991c; Sat, 07 Oct 2017 00:44:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v970id1L006990; Fri, 6 Oct 2017 18:44:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507337079.86205.282.camel@freebsd.org> Subject: Re: r324353: boot failure: failed with error 19 From: Ian Lepore To: "O. Hartmann" , Trond =?ISO-8859-1?Q?Endrest=F8l?= Cc: "O. Hartmann" , FreeBSD CURRENT , Warner Losh Date: Fri, 06 Oct 2017 18:44:39 -0600 In-Reply-To: <20171006223214.580eb09c@thor.intern.walstatt.dynvpn.de> References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> <20171006223214.580eb09c@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 00:45:58 -0000 On Fri, 2017-10-06 at 22:33 +0200, O. Hartmann wrote: > First of all, I think something has changed, since /dev/ufs doesn't get populated anymore > by usage of "gpart label" command. Second, there is a high chance that I messed up > NanoBSD a bit, a couple of days ago I tried to sync with the code base changes and I made > most changes effectively what is now "legacy.sh". Here is the crucial error...  Labels created with glabel are in /dev/label, they have never been in /dev/ufs. /dev/ufs is populated by the contents of ufs filesystem labels, which are created using "newfs -L" or "tunefs -L".  To see what label (if any) is on your root filesystem, use:   # dumpfs / | grep vol   volname roots1 swuid 0 providersize 262135 If nothing appears between "volname" and "swuid" it has no label. I'm not disputing something may have changed that is causing you problems, I'm just trying to point out that you are chasing the wrong cause based on some kind of misunderstanding of the symptoms. -- Ian From owner-freebsd-current@freebsd.org Sat Oct 7 07:58:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 199B6E30F10 for ; Sat, 7 Oct 2017 07:58:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 BD13C2FE5 for ; Sat, 7 Oct 2017 07:58:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1428 invoked from network); 7 Oct 2017 07:58:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 07:58:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 03:58:06 -0400 (EDT) Received: (qmail 31895 invoked from network); 7 Oct 2017 07:58:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 07:58:05 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 404F2EC918F; Sat, 7 Oct 2017 00:58:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: <20171007064249.GA73770@vlakno.cz> Date: Sat, 7 Oct 2017 00:58:04 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 07:58:14 -0000 On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: > Just to clarify my not agreeing with Mark regarding EH on ppc64. >=20 > Last time I tried to fix ppc64 exceptions handling as generated by = clang > it turned out that simply using gnu ld from ports fixes the issue. >=20 > For details see: > = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= Unfortunately my experiments failed to confirm this. Repeating them now under head -r324071 and ports -r450478 : # more exception_test.cpp=20 #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++14 -g -O2 = exception_test.cpp # ./a.out Segmentation fault (core dumped) # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp # ./a.out Segmentation fault (core dumped) # ls -lt /usr/local/powerpc64-freebsd/bin total 56704 lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> = ../../bin/powerpc64-freebsd-size -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++14 = -g -O2 exception_test.cpp # ./a.out Segmentation fault (core dumped) # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++11 = -g exception_test.cpp # ./a.out Segmentation fault (core dumped) # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ total 363584 -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 08:10:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8FADE31715 for ; Sat, 7 Oct 2017 08:10:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 9BCA63AEB for ; Sat, 7 Oct 2017 08:10:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14179 invoked from network); 7 Oct 2017 08:10:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 08:10:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 04:10:43 -0400 (EDT) Received: (qmail 17648 invoked from network); 7 Oct 2017 08:10:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 08:10:43 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 92406EC918F; Sat, 7 Oct 2017 01:10:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Sat, 7 Oct 2017 01:10:42 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 08:10:46 -0000 [I'm adding examples with output from clang -v since it explicitly shows the path used for ld and such.] On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: > On 2017-Oct-6, at 11:42 PM, Roman Divacky = wrote: >=20 >> Just to clarify my not agreeing with Mark regarding EH on ppc64. >>=20 >> Last time I tried to fix ppc64 exceptions handling as generated by = clang >> it turned out that simply using gnu ld from ports fixes the issue. >>=20 >> For details see: >> = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= >=20 > Unfortunately my experiments failed to confirm this. Repeating > them now under head -r324071 and ports -r450478 : >=20 > # more exception_test.cpp=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 > # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++14 -g -O2 = exception_test.cpp >=20 > # ./a.out > Segmentation fault (core dumped) >=20 > # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >=20 > # ./a.out > Segmentation fault (core dumped) # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj = -mrelax-all -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=3Dc++11 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=3Dgnustep = -fcxx-exceptions -fexceptions -fdiagnostics-show-option = -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ = exception_test.cpp clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker = /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o # ./a.out Segmentation fault (core dumped) > # ls -lt /usr/local/powerpc64-freebsd/bin > total 56704 > lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> = ../../bin/powerpc64-freebsd-size > -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld > -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd > -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as > -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip > -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm > -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf > -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy > -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib > -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar > -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >=20 > # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++14 = -g -O2 exception_test.cpp >=20 > # ./a.out > Segmentation fault (core dumped) # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++14= -g -O2 exception_test.cpp FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj = -disable-free -main-file-name exception_test.cpp -mrelocation-model pic = -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose = -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v = -dwarf-column-info -debug-info-kind=3Dstandalone -dwarf-version=3D2 = -debugger-tuning=3Dgdb -resource-dir /usr/lib/clang/5.0.0 = -internal-isystem /usr/include/c++/v1 -O2 -std=3Dc++14 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=3Dgnustep = -fcxx-exceptions -fexceptions -fdiagnostics-show-option = -fcolor-diagnostics -vectorize-loops -vectorize-slp -o = /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-3ebf72.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o # ./a.out Segmentation fault (core dumped) > # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++11 = -g exception_test.cpp >=20 > # ./a.out > Segmentation fault (core dumped) >=20 >=20 > # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ > total 363584 > -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld > -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd > -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as > -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip > -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm > -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf > -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool > -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy > -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib > -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar > -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 09:18:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 408B5E33758 for ; Sat, 7 Oct 2017 09:18:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 CBEA16942B for ; Sat, 7 Oct 2017 09:18:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10116 invoked from network); 7 Oct 2017 09:18:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 09:18:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 05:18:38 -0400 (EDT) Received: (qmail 3426 invoked from network); 7 Oct 2017 09:18:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 09:18:38 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A6FB2EC918F; Sat, 7 Oct 2017 02:18:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Sat, 7 Oct 2017 02:18:37 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 09:18:41 -0000 [I'm separately listing backtrace information and related information from one of core dumps and going back through the details to see if they seem to be as they were back then. Read only if you care. It does look the same as I found back then if I remember right. I reach the same conclusion I reached back then anyway. I give evidence in the below.] On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > [I'm adding examples with output from clang -v since it explicitly = shows > the path used for ld and such.] >=20 > On 2017-Oct-7, at 12:58 AM, Mark Millard = wrote: >=20 >> On 2017-Oct-6, at 11:42 PM, Roman Divacky = wrote: >>=20 >>> Just to clarify my not agreeing with Mark regarding EH on ppc64. >>>=20 >>> Last time I tried to fix ppc64 exceptions handling as generated by = clang >>> it turned out that simply using gnu ld from ports fixes the issue. >>>=20 >>> For details see: >>> = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= >>=20 >> Unfortunately my experiments failed to confirm this. Repeating >> them now under head -r324071 and ports -r450478 : >>=20 >> # more exception_test.cpp=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++14 -g -O2 = exception_test.cpp >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >>=20 >> # ./a.out >> Segmentation fault (core dumped) >=20 > # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=3Dc++11 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=3Dgnustep = -fcxx-exceptions -fexceptions -fdiagnostics-show-option = -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ = exception_test.cpp > clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/include/c++/v1 > /usr/lib/clang/5.0.0/include > /usr/include > End of search list. > "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker = /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >=20 > # ./a.out > Segmentation fault (core dumped) >=20 >=20 >> # ls -lt /usr/local/powerpc64-freebsd/bin >> total 56704 >> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> = ../../bin/powerpc64-freebsd-size >> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm >> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf >> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy >> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib >> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar >> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >>=20 >> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++14= -g -O2 exception_test.cpp >>=20 >> # ./a.out >> Segmentation fault (core dumped) >=20 > # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++14 -g -O2 exception_test.cpp > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -O2 = -std=3Dc++14 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests = -ferror-limit 19 -fmessage-length 200 -fno-signed-char = -fobjc-runtime=3Dgnustep -fcxx-exceptions -fexceptions = -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops = -vectorize-slp -o /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp > clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/include/c++/v1 > /usr/lib/clang/5.0.0/include > /usr/include > End of search list. > "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-3ebf72.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >=20 > # ./a.out > Segmentation fault (core dumped) >=20 >> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=3Dc++11= -g exception_test.cpp >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >>=20 >> # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ >> total 363584 >> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld >> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd >> -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as >> -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip >> -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm >> -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf >> -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool >> -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy >> -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib >> -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar >> -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump [Note: I used /usr/libexec/gdb because /usr/local/bin/gdb core dumps for this. powerpc64 is an example of the devel/gdb port currently being worse than the system gdb in various cases.] # /usr/libexec/gdb a.out /var/crash/a.out.12775.core=20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "powerpc64-marcel-freebsd"... Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. done. . . . Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc70) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc70) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000d74 in main () at exception_test.cpp:5 #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc70, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 . . . __gxx_personality_v0 was trying to execute: _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), reinterpret_cast(exceptionObject)); That was part of the sequence: . . . _Unwind_SetIP(context, reinterpret_cast(action.landing_pad)); _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), reinterpret_cast(exceptionObject)); _Unwind_SetGR(context, __builtin_eh_return_data_regno(1), = selector); return _URC_INSTALL_CONTEXT; So it died trying to use the CFA information for one of the scratch registers, the one used for the "exceptionObject". The details are: inline void _Unwind_SetGR (struct _Unwind_Context *context, int index, _Unwind_Word = val) { int size; void *ptr; index =3D DWARF_REG_TO_UNWIND_COLUMN (index); gcc_assert (index < (int) sizeof(dwarf_reg_size_table)); size =3D dwarf_reg_size_table[index]; if (_Unwind_IsExtendedContext (context) && context->by_value[index]) { context->reg[index] =3D (void *) (_Unwind_Internal_Ptr) val; return; } ptr =3D context->reg[index]; if (size =3D=3D sizeof(_Unwind_Ptr)) * (_Unwind_Ptr *) ptr =3D val; else { gcc_assert (size =3D=3D sizeof(_Unwind_Word)); * (_Unwind_Word *) ptr =3D val; } } Note: DWARF_REG_TO_UNWIND_COLUMN leaves the index value unchanged for the value involved. I'll not provide the evidence here. Breakpoint 1, main () at exception_test.cpp:5 5 try { throw std::exception(); } (gdb) br _Unwind_SetGR Breakpoint 2 at 0x50530bbc (gdb) c Continuing. Breakpoint 2, _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 207 index =3D DWARF_REG_TO_UNWIND_COLUMN (index); Current language: auto; currently minimal (gdb) bt #0 _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc30) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc30) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000d74 in main () at exception_test.cpp:5 #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc30, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 (gdb) print *context $2 =3D {reg =3D 0xffffffffffffcc30, cfa =3D 0xffffffffffffd990, ra =3D = 0x10000d78, lsda =3D 0x10000f74, bases =3D {tbase =3D 0x0, dbase =3D = 0x0, func =3D 0x10000d30}, flags =3D 4611686018427387904, version =3D 0,=20= args_size =3D 0, by_value =3D 0xffffffffffffd108 ""} (gdb) print dwarf_reg_size_table[3] $3 =3D 8 '\b' (gdb) print context->reg[3] $4 =3D (void *) 0x0 And there is the problem: lack of the value that is supposed to be available there: NULL instead. This traces back to. . . # dwarfdump -v -v -F a.out .eh_frame fde: < 0><0x100007a0:0x10000800><> 0x100007a0: =20 fde section offset 24 0x00000018 cie offset for fde: 28 0x0000001c 0 DW_CFA_nop 1 DW_CFA_nop 2 DW_CFA_nop 3 DW_CFA_nop 4 DW_CFA_nop 5 DW_CFA_nop 6 DW_CFA_nop < 1><0x10000d30:0x10000dac>
0x10000d30: =20 0x10000d40: =20 0x10000d44: =20 fde section offset 104 0x00000068 cie offset for fde: 36 0x00000024 0 DW_CFA_advance_loc 16 (4 * 4) 1 DW_CFA_def_cfa_offset 128 4 DW_CFA_offset r31 -8 (1 * -8) 6 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 9 DW_CFA_advance_loc 4 (1 * 4) 10 DW_CFA_def_cfa_register r31 12 DW_CFA_nop 13 DW_CFA_nop 14 DW_CFA_nop < 2><0x10000e38:0x10000e90><> 0x10000e38: =20 0x10000e3c: =20 0x10000e4c: =20 fde section offset 48 0x00000030 cie offset for fde: 52 0x00000034 0 DW_CFA_advance_loc 4 (1 * 4) 1 DW_CFA_register r65 =3D r12 4 DW_CFA_advance_loc 16 (4 * 4) 5 DW_CFA_restore_extended r65 cie: < 0> version 1 cie section offset 0 0x00000000 augmentation zR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0x1 bytes 0x1b=20 bytes of initial instructions 7 cie length 20 initial instructions 0 DW_CFA_def_cfa r1 0 3 DW_CFA_nop 4 DW_CFA_nop 5 DW_CFA_nop 6 DW_CFA_nop < 1> version 1 cie section offset 72 0x00000048 augmentation zPLR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0xb bytes 0x94 00 00 00 00 00 01 04 a5 14 1b=20 bytes of initial instructions 3 cie length 28 initial instructions 0 DW_CFA_def_cfa r1 0 Which is missing the DW_CFA_ material for the scratch registers (such as the one tied to index 3 for the exceptionObject) so the context->reg[3] value at run-time was junk (NULL) by not having been filled in. Thus the code fails. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 09:54:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8993E340C3 for ; Sat, 7 Oct 2017 09:54:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 62C5F70017 for ; Sat, 7 Oct 2017 09:54:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12347 invoked from network); 7 Oct 2017 09:54:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 09:54:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 05:54:36 -0400 (EDT) Received: (qmail 17895 invoked from network); 7 Oct 2017 09:54:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 09:54:36 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 88223EC918F; Sat, 7 Oct 2017 02:54:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Sat, 7 Oct 2017 02:54:35 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 09:54:38 -0000 [The last part of my note has a dumb mistake, not that it messes up the other evidence. I should have dwarfdump'd not a.out but the code in the libraries, such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I made the same mistake initially back when Roman and I were dealing with this long ago. Correcting it again. . .] On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > [I'm separately listing backtrace information and related > information from one of core dumps and going back through > the details to see if they seem to be as they were back > then. Read only if you care. It does look the same as I > found back then if I remember right. I reach the same > conclusion I reached back then anyway. I give evidence > in the below.] >=20 > On 2017-Oct-7, at 1:10 AM, Mark Millard = wrote: >=20 >> [I'm adding examples with output from clang -v since it explicitly = shows >> the path used for ld and such.] >>=20 >> On 2017-Oct-7, at 12:58 AM, Mark Millard = wrote: >>=20 >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky = wrote: >>>=20 >>>> Just to clarify my not agreeing with Mark regarding EH on ppc64. >>>>=20 >>>> Last time I tried to fix ppc64 exceptions handling as generated by = clang >>>> it turned out that simply using gnu ld from ports fixes the issue. >>>>=20 >>>> For details see: >>>> = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= >>>=20 >>> Unfortunately my experiments failed to confirm this. Repeating >>> them now under head -r324071 and ports -r450478 : >>>=20 >>> # more exception_test.cpp=20 >>> #include >>>=20 >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>>=20 >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++14 -g -O2 = exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>>=20 >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>=20 >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=3Dc++11 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=3Dgnustep = -fcxx-exceptions -fexceptions -fdiagnostics-show-option = -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ = exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker = /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >>=20 >>> # ls -lt /usr/local/powerpc64-freebsd/bin >>> total 56704 >>> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> = ../../bin/powerpc64-freebsd-size >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >>> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >>> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >>> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm >>> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf >>> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy >>> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib >>> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar >>> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >>>=20 >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++14 -g -O2 exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>=20 >> # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++14 -g -O2 exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -O2 = -std=3Dc++14 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests = -ferror-limit 19 -fmessage-length 200 -fno-signed-char = -fobjc-runtime=3Dgnustep -fcxx-exceptions -fexceptions = -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops = -vectorize-slp -o /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-3ebf72.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++11 -g exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>>=20 >>>=20 >>> # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ >>> total 363584 >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd >>> -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as >>> -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip >>> -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm >>> -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf >>> -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool >>> -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy >>> -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib >>> -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar >>> -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump >=20 > [Note: I used /usr/libexec/gdb because /usr/local/bin/gdb > core dumps for this. powerpc64 is an example of the > devel/gdb port currently being worse than the system gdb > in various cases.] >=20 > # /usr/libexec/gdb a.out /var/crash/a.out.12775.core=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc64-marcel-freebsd"... > Core was generated by `./a.out'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. > done. > . . . > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 > 162 { > (gdb) bt > #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 > #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 > context=3D0xffffffffffffcc70) at = /usr/src/contrib/libcxxrt/exception.cc:1203 > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 = (exc=3D0x50042060, context=3D0xffffffffffffcc70) at unwind.inc:66 > #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc70, obj=3D, cleanup=3D, ps_strings=3D) > at /usr/src/lib/csu/powerpc64/crt1.c:94 > #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >=20 > . . . >=20 > __gxx_personality_v0 was trying to execute: >=20 > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > reinterpret_cast(exceptionObject)); >=20 > That was part of the sequence: >=20 > . . . > _Unwind_SetIP(context, reinterpret_cast(action.landing_pad)); > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > reinterpret_cast(exceptionObject)); > _Unwind_SetGR(context, __builtin_eh_return_data_regno(1), = selector); >=20 > return _URC_INSTALL_CONTEXT; >=20 >=20 > So it died trying to use the CFA information for one of > the scratch registers, the one used for the "exceptionObject". >=20 > The details are: >=20 > inline void > _Unwind_SetGR (struct _Unwind_Context *context, int index, = _Unwind_Word val) > { > int size; > void *ptr; >=20 > index =3D DWARF_REG_TO_UNWIND_COLUMN (index); > gcc_assert (index < (int) sizeof(dwarf_reg_size_table)); > size =3D dwarf_reg_size_table[index]; >=20 > if (_Unwind_IsExtendedContext (context) && context->by_value[index]) > { > context->reg[index] =3D (void *) (_Unwind_Internal_Ptr) val; > return; > } >=20 > ptr =3D context->reg[index]; >=20 > if (size =3D=3D sizeof(_Unwind_Ptr)) > * (_Unwind_Ptr *) ptr =3D val; > else > { > gcc_assert (size =3D=3D sizeof(_Unwind_Word)); > * (_Unwind_Word *) ptr =3D val; > } > } >=20 > Note: DWARF_REG_TO_UNWIND_COLUMN leaves the index value > unchanged for the value involved. I'll not provide the > evidence here. >=20 > Breakpoint 1, main () at exception_test.cpp:5 > 5 try { throw std::exception(); } > (gdb) br _Unwind_SetGR > Breakpoint 2 at 0x50530bbc > (gdb) c > Continuing. >=20 > Breakpoint 2, _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > 207 index =3D DWARF_REG_TO_UNWIND_COLUMN (index); > Current language: auto; currently minimal > (gdb) bt > #0 _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 > context=3D0xffffffffffffcc30) at = /usr/src/contrib/libcxxrt/exception.cc:1203 > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 = (exc=3D0x50042060, context=3D0xffffffffffffcc30) at unwind.inc:66 > #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc30, obj=3D, cleanup=3D, ps_strings=3D) > at /usr/src/lib/csu/powerpc64/crt1.c:94 > #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > (gdb) print *context > $2 =3D {reg =3D 0xffffffffffffcc30, cfa =3D 0xffffffffffffd990, ra =3D = 0x10000d78, lsda =3D 0x10000f74, bases =3D {tbase =3D 0x0, dbase =3D = 0x0, func =3D 0x10000d30}, flags =3D 4611686018427387904, version =3D 0,=20= > args_size =3D 0, by_value =3D 0xffffffffffffd108 ""} > (gdb) print dwarf_reg_size_table[3] > $3 =3D 8 '\b' > (gdb) print context->reg[3] > $4 =3D (void *) 0x0 >=20 > And there is the problem: lack of the value > that is supposed to be available there: NULL > instead. >=20 > This traces back to. . . . . . (removed mistake) . . . Quoting an old note to Roman: The landing pad area includes the __cxa_being_catch and __cxa_end_catch and the involved code from /lib/libcxxrt.so.1 should have the scratch-register CFI entries, not the above main code. So there was no point to my listing the CFI information for main. End Quote. The below points out where there should have been CFI information for the scratch registers, including the failing r3 use. (Below is essentially my self- correction text that I sent to Roman long ago.) # ldd a.out a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x5004e000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5017b000) libm.so.5 =3D> /lib/libm.so.5 (0x501a2000) libc.so.7 =3D> /lib/libc.so.7 (0x501da000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5052c000) The used scratch registers (of r3, r4, r5, r6) should show up in: # dwarfdump -v -v -F /lib/libcxxrt.so.1 | egrep -i "\" # but do not. In __cxa_begin_catch below note the code setting up r3-r5 before the branch to __cxa_begin_catch+164 and that __cxa_begin_catch+164 on is exit code that leaves these scratch register alone. (The path skipping __cxa_begin_catch+144 is similar for the issue.) __cxa_being_catch's CFI information should list the r3, r4, and r5 scratch register usage but does not. (Powerpc 32-bit has the same issue for the same registers for its __cxa_begin_catch .) (gdb) Dump of assembler code for function __cxa_begin_catch: 0x000000005018ecc4 <__cxa_begin_catch+0>: mflr r0 0x000000005018ecc8 <__cxa_begin_catch+4>: std r0,16(r1) 0x000000005018eccc <__cxa_begin_catch+8>: stdu r1,-144(r1) 0x000000005018ecd0 <__cxa_begin_catch+12>: std r29,120(r1) 0x000000005018ecd4 <__cxa_begin_catch+16>: std r30,128(r1) 0x000000005018ecd8 <__cxa_begin_catch+20>: mr r29,r3 0x000000005018ecdc <__cxa_begin_catch+24>: bl 0x5018e634 = <_ZL11thread_infov> 0x000000005018ece0 <__cxa_begin_catch+28>: mr r30,r3 0x000000005018ece4 <__cxa_begin_catch+32>: lwz r3,48(r30) 0x000000005018ece8 <__cxa_begin_catch+36>: addi r3,r3,-1 0x000000005018ecec <__cxa_begin_catch+40>: stw r3,48(r30) 0x000000005018ecf0 <__cxa_begin_catch+44>: ld r3,0(r29) 0x000000005018ecf4 <__cxa_begin_catch+48>: bl 0x50190210 = <_ZL14isCXXExceptionm> 0x000000005018ecf8 <__cxa_begin_catch+52>: cmpldi r3,0 0x000000005018ecfc <__cxa_begin_catch+56>: beq- 0x5018ed44 = <__cxa_begin_catch+128> 0x000000005018ed00 <__cxa_begin_catch+60>: mr r3,r29 0x000000005018ed04 <__cxa_begin_catch+64>: bl 0x5018f81c = <_ZL20exceptionFromPointerPv> 0x000000005018ed08 <__cxa_begin_catch+68>: lwz r4,48(r3) 0x000000005018ed0c <__cxa_begin_catch+72>: cmplwi r4,0 0x000000005018ed10 <__cxa_begin_catch+76>: bne- 0x5018ed20 = <__cxa_begin_catch+92> 0x000000005018ed14 <__cxa_begin_catch+80>: ld r5,40(r30) 0x000000005018ed18 <__cxa_begin_catch+84>: std r5,40(r3) 0x000000005018ed1c <__cxa_begin_catch+88>: std r3,40(r30) 0x000000005018ed20 <__cxa_begin_catch+92>: srawi r5,r4,31 0x000000005018ed24 <__cxa_begin_catch+96>: li r29,0 0x000000005018ed28 <__cxa_begin_catch+100>: add r4,r4,r5 0x000000005018ed2c <__cxa_begin_catch+104>: xor r4,r4,r5 0x000000005018ed30 <__cxa_begin_catch+108>: addi r4,r4,1 0x000000005018ed34 <__cxa_begin_catch+112>: stw r4,48(r3) 0x000000005018ed38 <__cxa_begin_catch+116>: stw r29,32(r30) 0x000000005018ed3c <__cxa_begin_catch+120>: ld r3,80(r3) 0x000000005018ed40 <__cxa_begin_catch+124>: b 0x5018ed68 = <__cxa_begin_catch+164> 0x000000005018ed44 <__cxa_begin_catch+128>: ld r3,40(r30) 0x000000005018ed48 <__cxa_begin_catch+132>: cmpldi r3,0 0x000000005018ed4c <__cxa_begin_catch+136>: beq- 0x5018ed58 = <__cxa_begin_catch+148> 0x000000005018ed50 <__cxa_begin_catch+140>: bl 0x50184480 = <00000017.plt_call._ZSt9terminatev> 0x000000005018ed54 <__cxa_begin_catch+144>: ld r2,40(r1) 0x000000005018ed58 <__cxa_begin_catch+148>: addi r3,r29,32 0x000000005018ed5c <__cxa_begin_catch+152>: li r4,1 0x000000005018ed60 <__cxa_begin_catch+156>: std r29,40(r30) 0x000000005018ed64 <__cxa_begin_catch+160>: stw r4,32(r30) 0x000000005018ed68 <__cxa_begin_catch+164>: ld r30,128(r1) 0x000000005018ed6c <__cxa_begin_catch+168>: ld r29,120(r1) 0x000000005018ed70 <__cxa_begin_catch+172>: addi r1,r1,144 0x000000005018ed74 <__cxa_begin_catch+176>: ld r0,16(r1) 0x000000005018ed78 <__cxa_begin_catch+180>: mtlr r0 0x000000005018ed7c <__cxa_begin_catch+184>: blr 0x000000005018ed80 <__cxa_begin_catch+188>: .long 0x0 0x000000005018ed84 <__cxa_begin_catch+192>: .long 0x0 0x000000005018ed88 <__cxa_begin_catch+196>: .long 0x0 End of assembler dump. Sorry for the earlier mis-direction. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 10:13:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAA69E34817 for ; Sat, 7 Oct 2017 10:13:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 95B76739CD for ; Sat, 7 Oct 2017 10:13:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 539 invoked from network); 7 Oct 2017 10:13:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 10:13:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 06:13:44 -0400 (EDT) Received: (qmail 25296 invoked from network); 7 Oct 2017 10:13:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 10:13:44 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD506EC954D; Sat, 7 Oct 2017 03:13:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: Date: Sat, 7 Oct 2017 03:13:43 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 10:13:47 -0000 Just a short top-post as this does not fit well with the other material: I believe Roman only built his example program with clang, not the world that the program was being run under. The gcc 4.2.1 based code that is analogous to __cxa_begin_catch (scratch register initialization) in a clang based build world has the scratch register CFI material and the same clang produced a.out file works fine under such a system (simply copied over and run). And that is why Roman's context did not SIGSEGV but mine did: I used clang for the buildworld for the world that was being used and so __cxa_begin_catch was missing CFI information in my build. In fact the a.out built by gcc 4.2.1 fails under the clang based buildworld with the bad __cxa_begin_catch . The only thing that matters is the system library code involved, not which a.out (from which compiler). On 2017-Oct-7, at 2:54 AM, Mark Millard wrote: [The last part of my note has a dumb mistake, not that it messes up the other evidence. I should have dwarfdump'd not a.out but the code in the libraries, such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I made the same mistake initially back when Roman and I were dealing with this long ago. Correcting it again. . .] On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > [I'm separately listing backtrace information and related > information from one of core dumps and going back through > the details to see if they seem to be as they were back > then. Read only if you care. It does look the same as I > found back then if I remember right. I reach the same > conclusion I reached back then anyway. I give evidence > in the below.] >=20 > On 2017-Oct-7, at 1:10 AM, Mark Millard = wrote: >=20 >> [I'm adding examples with output from clang -v since it explicitly = shows >> the path used for ld and such.] >>=20 >> On 2017-Oct-7, at 12:58 AM, Mark Millard = wrote: >>=20 >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky = wrote: >>>=20 >>>> Just to clarify my not agreeing with Mark regarding EH on ppc64. >>>>=20 >>>> Last time I tried to fix ppc64 exceptions handling as generated by = clang >>>> it turned out that simply using gnu ld from ports fixes the issue. >>>>=20 >>>> For details see: >>>> = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= >>>=20 >>> Unfortunately my experiments failed to confirm this. Repeating >>> them now under head -r324071 and ports -r450478 : >>>=20 >>> # more exception_test.cpp=20 >>> #include >>>=20 >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>>=20 >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++14 -g -O2 = exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>>=20 >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>=20 >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=3Dc++11 -g = exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=3Dc++11 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=3Dgnustep = -fcxx-exceptions -fexceptions -fdiagnostics-show-option = -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ = exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker = /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >>=20 >>> # ls -lt /usr/local/powerpc64-freebsd/bin >>> total 56704 >>> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> = ../../bin/powerpc64-freebsd-size >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >>> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >>> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >>> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm >>> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf >>> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy >>> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib >>> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar >>> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >>>=20 >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++14 -g -O2 exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>=20 >> # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++14 -g -O2 exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 = -emit-obj -disable-free -main-file-name exception_test.cpp = -mrelocation-model pic -pic-level 2 -mthread-model posix = -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 = -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=3Dstandalone = -dwarf-version=3D2 -debugger-tuning=3Dgdb -resource-dir = /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -O2 = -std=3Dc++14 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests = -ferror-limit 19 -fmessage-length 200 -fno-signed-char = -fobjc-runtime=3Dgnustep -fcxx-exceptions -fexceptions = -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops = -vectorize-slp -o /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target = powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-3ebf72.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >>=20 >> # ./a.out >> Segmentation fault (core dumped) >>=20 >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ = -std=3Dc++11 -g exception_test.cpp >>>=20 >>> # ./a.out >>> Segmentation fault (core dumped) >>>=20 >>>=20 >>> # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ >>> total 363584 >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd >>> -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as >>> -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip >>> -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm >>> -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf >>> -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool >>> -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy >>> -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib >>> -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar >>> -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump >=20 > [Note: I used /usr/libexec/gdb because /usr/local/bin/gdb > core dumps for this. powerpc64 is an example of the > devel/gdb port currently being worse than the system gdb > in various cases.] >=20 > # /usr/libexec/gdb a.out /var/crash/a.out.12775.core=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc64-marcel-freebsd"... > Core was generated by `./a.out'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. > done. > . . . > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 > 162 { > (gdb) bt > #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 > #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 > context=3D0xffffffffffffcc70) at = /usr/src/contrib/libcxxrt/exception.cc:1203 > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 = (exc=3D0x50042060, context=3D0xffffffffffffcc70) at unwind.inc:66 > #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc70, obj=3D, cleanup=3D, ps_strings=3D) > at /usr/src/lib/csu/powerpc64/crt1.c:94 > #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >=20 > . . . >=20 > __gxx_personality_v0 was trying to execute: >=20 > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > reinterpret_cast(exceptionObject)); >=20 > That was part of the sequence: >=20 > . . . > _Unwind_SetIP(context, reinterpret_cast(action.landing_pad)); > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > reinterpret_cast(exceptionObject)); > _Unwind_SetGR(context, __builtin_eh_return_data_regno(1), = selector); >=20 > return _URC_INSTALL_CONTEXT; >=20 >=20 > So it died trying to use the CFA information for one of > the scratch registers, the one used for the "exceptionObject". >=20 > The details are: >=20 > inline void > _Unwind_SetGR (struct _Unwind_Context *context, int index, = _Unwind_Word val) > { > int size; > void *ptr; >=20 > index =3D DWARF_REG_TO_UNWIND_COLUMN (index); > gcc_assert (index < (int) sizeof(dwarf_reg_size_table)); > size =3D dwarf_reg_size_table[index]; >=20 > if (_Unwind_IsExtendedContext (context) && context->by_value[index]) > { > context->reg[index] =3D (void *) (_Unwind_Internal_Ptr) val; > return; > } >=20 > ptr =3D context->reg[index]; >=20 > if (size =3D=3D sizeof(_Unwind_Ptr)) > * (_Unwind_Ptr *) ptr =3D val; > else > { > gcc_assert (size =3D=3D sizeof(_Unwind_Word)); > * (_Unwind_Word *) ptr =3D val; > } > } >=20 > Note: DWARF_REG_TO_UNWIND_COLUMN leaves the index value > unchanged for the value involved. I'll not provide the > evidence here. >=20 > Breakpoint 1, main () at exception_test.cpp:5 > 5 try { throw std::exception(); } > (gdb) br _Unwind_SetGR > Breakpoint 2 at 0x50530bbc > (gdb) c > Continuing. >=20 > Breakpoint 2, _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > 207 index =3D DWARF_REG_TO_UNWIND_COLUMN (index); > Current language: auto; currently minimal > (gdb) bt > #0 _Unwind_SetGR (context=3D0xffffffffffffcc30, index=3D3, = val=3D1342447712) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 > context=3D0xffffffffffffcc30) at = /usr/src/contrib/libcxxrt/exception.cc:1203 > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 = (exc=3D0x50042060, context=3D0xffffffffffffcc30) at unwind.inc:66 > #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc30, obj=3D, cleanup=3D, ps_strings=3D) > at /usr/src/lib/csu/powerpc64/crt1.c:94 > #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > (gdb) print *context > $2 =3D {reg =3D 0xffffffffffffcc30, cfa =3D 0xffffffffffffd990, ra =3D = 0x10000d78, lsda =3D 0x10000f74, bases =3D {tbase =3D 0x0, dbase =3D = 0x0, func =3D 0x10000d30}, flags =3D 4611686018427387904, version =3D 0,=20= > args_size =3D 0, by_value =3D 0xffffffffffffd108 ""} > (gdb) print dwarf_reg_size_table[3] > $3 =3D 8 '\b' > (gdb) print context->reg[3] > $4 =3D (void *) 0x0 >=20 > And there is the problem: lack of the value > that is supposed to be available there: NULL > instead. >=20 > This traces back to. . . . . . (removed mistake) . . . Quoting an old note to Roman: The landing pad area includes the __cxa_being_catch and __cxa_end_catch and the involved code from /lib/libcxxrt.so.1 should have the scratch-register CFI entries, not the above main code. So there was no point to my listing the CFI information for main. End Quote. The below points out where there should have been CFI information for the scratch registers, including the failing r3 use. (Below is essentially my self- correction text that I sent to Roman long ago.) # ldd a.out a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x5004e000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5017b000) libm.so.5 =3D> /lib/libm.so.5 (0x501a2000) libc.so.7 =3D> /lib/libc.so.7 (0x501da000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5052c000) The used scratch registers (of r3, r4, r5, r6) should show up in: # dwarfdump -v -v -F /lib/libcxxrt.so.1 | egrep -i "\" # but do not. In __cxa_begin_catch below note the code setting up r3-r5 before the branch to __cxa_begin_catch+164 and that __cxa_begin_catch+164 on is exit code that leaves these scratch register alone. (The path skipping __cxa_begin_catch+144 is similar for the issue.) __cxa_being_catch's CFI information should list the r3, r4, and r5 scratch register usage but does not. (Powerpc 32-bit has the same issue for the same registers for its __cxa_begin_catch .) (gdb) Dump of assembler code for function __cxa_begin_catch: 0x000000005018ecc4 <__cxa_begin_catch+0>: mflr r0 0x000000005018ecc8 <__cxa_begin_catch+4>: std r0,16(r1) 0x000000005018eccc <__cxa_begin_catch+8>: stdu r1,-144(r1) 0x000000005018ecd0 <__cxa_begin_catch+12>: std r29,120(r1) 0x000000005018ecd4 <__cxa_begin_catch+16>: std r30,128(r1) 0x000000005018ecd8 <__cxa_begin_catch+20>: mr r29,r3 0x000000005018ecdc <__cxa_begin_catch+24>: bl 0x5018e634 = <_ZL11thread_infov> 0x000000005018ece0 <__cxa_begin_catch+28>: mr r30,r3 0x000000005018ece4 <__cxa_begin_catch+32>: lwz r3,48(r30) 0x000000005018ece8 <__cxa_begin_catch+36>: addi r3,r3,-1 0x000000005018ecec <__cxa_begin_catch+40>: stw r3,48(r30) 0x000000005018ecf0 <__cxa_begin_catch+44>: ld r3,0(r29) 0x000000005018ecf4 <__cxa_begin_catch+48>: bl 0x50190210 = <_ZL14isCXXExceptionm> 0x000000005018ecf8 <__cxa_begin_catch+52>: cmpldi r3,0 0x000000005018ecfc <__cxa_begin_catch+56>: beq- 0x5018ed44 = <__cxa_begin_catch+128> 0x000000005018ed00 <__cxa_begin_catch+60>: mr r3,r29 0x000000005018ed04 <__cxa_begin_catch+64>: bl 0x5018f81c = <_ZL20exceptionFromPointerPv> 0x000000005018ed08 <__cxa_begin_catch+68>: lwz r4,48(r3) 0x000000005018ed0c <__cxa_begin_catch+72>: cmplwi r4,0 0x000000005018ed10 <__cxa_begin_catch+76>: bne- 0x5018ed20 = <__cxa_begin_catch+92> 0x000000005018ed14 <__cxa_begin_catch+80>: ld r5,40(r30) 0x000000005018ed18 <__cxa_begin_catch+84>: std r5,40(r3) 0x000000005018ed1c <__cxa_begin_catch+88>: std r3,40(r30) 0x000000005018ed20 <__cxa_begin_catch+92>: srawi r5,r4,31 0x000000005018ed24 <__cxa_begin_catch+96>: li r29,0 0x000000005018ed28 <__cxa_begin_catch+100>: add r4,r4,r5 0x000000005018ed2c <__cxa_begin_catch+104>: xor r4,r4,r5 0x000000005018ed30 <__cxa_begin_catch+108>: addi r4,r4,1 0x000000005018ed34 <__cxa_begin_catch+112>: stw r4,48(r3) 0x000000005018ed38 <__cxa_begin_catch+116>: stw r29,32(r30) 0x000000005018ed3c <__cxa_begin_catch+120>: ld r3,80(r3) 0x000000005018ed40 <__cxa_begin_catch+124>: b 0x5018ed68 = <__cxa_begin_catch+164> 0x000000005018ed44 <__cxa_begin_catch+128>: ld r3,40(r30) 0x000000005018ed48 <__cxa_begin_catch+132>: cmpldi r3,0 0x000000005018ed4c <__cxa_begin_catch+136>: beq- 0x5018ed58 = <__cxa_begin_catch+148> 0x000000005018ed50 <__cxa_begin_catch+140>: bl 0x50184480 = <00000017.plt_call._ZSt9terminatev> 0x000000005018ed54 <__cxa_begin_catch+144>: ld r2,40(r1) 0x000000005018ed58 <__cxa_begin_catch+148>: addi r3,r29,32 0x000000005018ed5c <__cxa_begin_catch+152>: li r4,1 0x000000005018ed60 <__cxa_begin_catch+156>: std r29,40(r30) 0x000000005018ed64 <__cxa_begin_catch+160>: stw r4,32(r30) 0x000000005018ed68 <__cxa_begin_catch+164>: ld r30,128(r1) 0x000000005018ed6c <__cxa_begin_catch+168>: ld r29,120(r1) 0x000000005018ed70 <__cxa_begin_catch+172>: addi r1,r1,144 0x000000005018ed74 <__cxa_begin_catch+176>: ld r0,16(r1) 0x000000005018ed78 <__cxa_begin_catch+180>: mtlr r0 0x000000005018ed7c <__cxa_begin_catch+184>: blr 0x000000005018ed80 <__cxa_begin_catch+188>: .long 0x0 0x000000005018ed84 <__cxa_begin_catch+192>: .long 0x0 0x000000005018ed88 <__cxa_begin_catch+196>: .long 0x0 End of assembler dump. Sorry for the earlier mis-direction. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 06:45:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBC0EE2FAD4 for ; Sat, 7 Oct 2017 06:45:41 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 636D184E0E for ; Sat, 7 Oct 2017 06:45:40 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 33C2ADF7DAB; Sat, 7 Oct 2017 08:42:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1507358569; bh=i6M6TvafR0218vcTs18tFc5u/hmpWlEMOoqhuO01h8Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=AnjTKYJclnogDNBjjfiGU6h9lIaCebZoRfUxiQcIdcwBpkUzIkuFceV5NQlP8zsJM u4T4MaXCC63fQAyLskSbPtk/xUlhx+05Vj9shnh2xLgEktOubzQebj8Msguh/FB3rH Tw/cKoaBwuECitsVOyqT7ASXPVLAgQEhtjmJLnWo= Date: Sat, 7 Oct 2017 08:42:49 +0200 From: Roman Divacky To: Mark Millard Cc: Justin Hibbits , Warner Losh , FreeBSD Current Subject: Re: C++ in jemalloc Message-ID: <20171007064249.GA73770@vlakno.cz> References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Mailman-Approved-At: Sat, 07 Oct 2017 10:53:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 06:45:42 -0000 Just to clarify my not agreeing with Mark regarding EH on ppc64. Last time I tried to fix ppc64 exceptions handling as generated by clang it turned out that simply using gnu ld from ports fixes the issue. For details see: https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html Roman On Fri, Oct 06, 2017 at 09:28:37AM -0700, Mark Millard wrote: > On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote: > > > Hi Mark, > > > > On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote: > >> Warner Losh imp at bsdimp.com wrote on > >> Thu Oct 5 21:01:26 UTC 2017 : > >> > >>> Starting in FreeBSD 11, arm and powerpc are supported by clang, > >>> but not super well. For FreeBSD 12, we're getting close for everything > >>> except sparc64 (whose fate has not yet been finally decided). > >> > >> My understanding of the powerpc and powerpc64 status > >> follows. This is based on my use of head via clang > >> as much as I can for them. > >> > >> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc : > >> > >> lld is far from working last I knew. (I've focused > >> more on the compilers for testing, using other > >> linkers and such.) [lldb may be in a similar state > >> for powerpc64. It does not build for powerpc.] > >> > >> clang 5 (and 4) generated code crashes on any thrown > >> C++ exception. For example: > >> > >> #include > >> > >> int main(void) > >> { > >> try { throw std::exception(); } > >> catch (std::exception& e) {} > >> return 0; > >> } > >> > >> crashes. > >> > >> Luckily most kernel and world code that I actively use > >> does not throw C++ exceptions in my use. > > > > Do you see this problem using libstdc++, et al, from base gcc 4.2.1? > > Or using libc++? > > gcc 4.2.1 buildkernel buildworld work fine for anything that I've > tried. They are libstdc++ based. > > I've not tried clang with libstdc++, just libc++. (Note: clang 3.8, > 3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals > tend to be from the earlier time frame. Many of my submittals for > other types of issues have been addressed. ) > > But my llvm bugzilla submittals for C++ exceptions indicate > errors/incompletenesses in the DW_CFA_ generation, such as > for scratch register handling. (Warning: I've not been through > the details in some time so this is from a vague memory.) 26844 > and 26856 are the relevant ones if I remember right. 31590 might > be relevant depending on what linunwind is to be used. > > Be warned that I do not believe Roman Divacky agrees with my > interpretation and I'd never studied the exception handling > techniques prior to these investigations. Still I think that > I was correct about there being problems in the DW_CFA_ > sequences generated. > > For a separate issue llvm 31716 is relevant for .plt and the > function descriptor layout. I use Roman Divacky's patch listing in > Comment 1. Included below as well. > > The llvm patches that I have are both from Roman as I remember: > > Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > =================================================================== > --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (revision 324071) > +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (working copy) > @@ -1178,7 +1178,7 @@ > // For SVR4, don't emit a move for the CR spill slot if we haven't > // spilled CRs. > if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4) > - && !MustSaveCR) > + && (!MustSaveCR && isPPC64)) > continue; > > // For 64-bit SVR4 when we have spilled CRs, the spill location > Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > =================================================================== > --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision 324071) > +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy) > @@ -60,7 +60,8 @@ > static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; } > > PPC64::PPC64() { > - PltRel = GotRel = R_PPC64_GLOB_DAT; > + GotRel = R_PPC64_GLOB_DAT; > + PltRel = R_PPC64_JMP_SLOT; > RelativeRel = R_PPC64_RELATIVE; > GotEntrySize = 8; > GotPltEntrySize = 8; > > > > > I don't have the time right now to look into it, but if no one else is > > able to in the next couple months I'll try to make the time when > > higher priorities are done. > > Are you familiar with what the DQ_CFA_ sequences should > be like given the powerpc scratch register usage and the > like? > > >> But devel/kyua is majorly broken by the C++ exception > >> issue: It makes extensive use of C++ exceptions. In my > >> view that disqualifies clang as being "close": I view > >> my activity as a hack until devel/kyua is generally > >> operable and so available for use in testing. > >> > >> clang 5 currently can not build the TARGET_ARCH=powerpc > >> kernel. (I was able to back in clang 4 days --but the > >> resultant build failed to execute init fully after > >> finishing the prior boot activity.) For the 32-bit > >> context I use gcc 4.2.1 for building the kernel and > >> clang 5 for building the world, system binutils > >> in use in both cases. > > > > What problem(s) do you see with this? If they're just compile time > > failures they can be fixed pretty readily. > > I submitted FreeBSD bugzilla 221107 for the: > > R_PPC_PLTREL24 reloc against local symbol > > failures. This was using system binutils. > > In a parallel builds it is a race between agp.* vs. > aha.* reporting this and stopping the build. > > > >> I do build the kernel and world for > >> TARGET_ARCH=powerpc64 via system clang 5. But I > >> use ports binutils as well in order for this to > >> finish and work overall. > >> > >> > >> As for more modern devel/powerpc64-xtoolchain-gcc > >> (so devel/powerpc64-gcc) versions being used to > >> build the world and kernel for powerpc64 I've never > >> been able to get lib32 on powerpc64 to work via > >> such a build: it builds but fails to execute from > >> dereferencing via an R30 that has an inappropriate > >> value for the attempt ( lib32/crtbeginS.o code in > >> _init in /usr/lib32/libc.so.* ). (The clang-based > >> builds do not have this problem.) It has been a > >> while since I've done devel/powerpc64-gcc > >> experiments. > >> > >> I'm not aware of a devel/powerpc-xtoolchain-gcc > >> as an alternative for 32-bit powerpc targeting. > > > > There's documentation floating around (on the wiki maybe?) for doing > > this. I won't check now, but it's not difficult (not trivial, but not > > difficult). With the proposal to eliminate gcc 4.2.1 from our tree by > > the end of the year, we need to get everything in place to make a > > seamless transition, whether it be to external toolchain or to finish > > up clang for powerpc. I really hope we can finish up clang. Please > > continue to file bugs with as much detail as necessary to track down > > and fix the problems--both in FreeBSD and upstream LLVM. > > I've never run into instructions for targeting 32-bit > powerpc FreeBSD via some gcc vintage/variant. As I > remember: When I tried I failed to figure out how to > et devel/powerpc64-gcc and related things to produce > what was needed. But I've not retried in a long time. > > > > My intended primary environment for FreeBSD build > activity is to be unavailable for a month or so. So > I'm currently limited to slower alternatives. Another > amd64 that I otherwise use for cross builds looks like > it will have to go out for repair. > > I did finally get both 32-bit and 64-bit powerpc to > jump from well before INO64 to fairly modern recently: > head -r324071 . Even the old iMac G3 boots the > 32-bit variant. > > > You might want to stop reading here. > > Details of /usr/src my activity is based on: > (some of the below list is not for powerpc > families) > > # svnlite status /usr/src | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/Makefile > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/arm64/arm64/mp_machdep.c > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > M /usr/src/sys/kern/subr_pcpu.c > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/interrupt.c > M /usr/src/sys/powerpc/powerpc/mp_machdep.c > M /usr/src/sys/powerpc/powerpc/trap.c > > I do have some patches trying to catch a problem > that I saw earlier for 32-bit powerpc FreeBSD on > old G5 PowerMacs but I've not seen the issue in a > long while. I also did something crude to libkvm to > get basic raw memory dumps working for that context > so I could examine stacks and other things. So some > of the powerpc C code files above just have some > sort of additional cross check code that is not > generally relevant. > > First I list things more directly tied to building > various ways not associated with those cross checks: > > Index: /usr/src/lib/Makefile > =================================================================== > --- /usr/src/lib/Makefile (revision 324071) > +++ /usr/src/lib/Makefile (working copy) > @@ -158,7 +158,7 @@ > .if ${MK_LIBCPLUSPLUS} != "no" > _libcxxrt= libcxxrt > _libcplusplus= libc++ > -.if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" > +.if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" && ${MACHINE_CPUARCH} != "powerpc" > _libcplusplus+= libc++experimental > .endif > .endif > > Index: /usr/src/sys/boot/ofw/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/ofw/Makefile.inc (revision 324071) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > -LDFLAGS+= -m elf32ppc_fbsd > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 324071) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > > Index: /usr/src/sys/boot/powerpc/boot1.chrp/Makefile > =================================================================== > --- /usr/src/sys/boot/powerpc/boot1.chrp/Makefile (revision 324071) > +++ /usr/src/sys/boot/powerpc/boot1.chrp/Makefile (working copy) > @@ -8,7 +8,7 @@ > INSTALLFLAGS= -b > > FILES= boot1.hfs > -SRCS= boot1.c ashldi3.c syncicache.c > +SRCS= boot1.c qdivrem.c udivdi3.c ashldi3.c syncicache.c > > MAN= > > > Index: /usr/src/sys/boot/powerpc/kboot/Makefile > =================================================================== > --- /usr/src/sys/boot/powerpc/kboot/Makefile (revision 324071) > +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) > @@ -69,8 +69,6 @@ > LIBFICL= ${.OBJDIR}/../../ficl/libficl.a > .endif > > -CFLAGS+= -mcpu=powerpc64 > - > # Always add MI sources > .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern > .include "${.CURDIR}/../../common/Makefile.inc" > @@ -86,9 +84,6 @@ > > LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc > > -# 64-bit bridge extensions > -CFLAGS+= -Wa,-mppc64bridge > - > # Pull in common loader code > #.PATH: ${.CURDIR}/../../ofw/common > #.include "${.CURDIR}/../../ofw/common/Makefile.inc" > > Index: /usr/src/sys/boot/uboot/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 324071) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > -LDFLAGS+= -m elf32ppc_fbsd > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > > Index: /usr/src/sys/conf/kmod.mk > =================================================================== > --- /usr/src/sys/conf/kmod.mk (revision 324071) > +++ /usr/src/sys/conf/kmod.mk (working copy) > @@ -151,8 +151,12 @@ > .endif > > .if ${MACHINE_CPUARCH} == powerpc > +.if ${COMPILER_TYPE} == "gcc" > CFLAGS+= -mlongcall -fno-omit-frame-pointer > +.else > +CFLAGS+= -fno-omit-frame-pointer > .endif > +.endif > > .if ${MACHINE_CPUARCH} == mips > CFLAGS+= -G0 -fno-pic -mno-abicalls -mlong-calls > > > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =================================================================== > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 324071) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -111,26 +111,27 @@ > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > -#ifdef __powerpc64__ > - __asm __volatile("mtsprg1 %0\n\t" > - "mtsprg2 %1\n\t" > - "mtsprg3 %2\n\t" > - : > - : "r"(ofmsr[2]), > - "r"(ofmsr[3]), > - "r"(ofmsr[4])); > -#else > - __asm __volatile("mfsprg0 %0\n\t" > - "mtsprg0 %1\n\t" > - "mtsprg1 %2\n\t" > - "mtsprg2 %3\n\t" > - "mtsprg3 %4\n\t" > - : "=&r"(ofw_sprg0_save) > - : "r"(ofmsr[1]), > - "r"(ofmsr[2]), > - "r"(ofmsr[3]), > - "r"(ofmsr[4])); > +#ifndef __powerpc64__ > + if (!(cpu_features & PPC_FEATURE_64)) > + __asm __volatile("mfsprg0 %0\n\t" > + "mtsprg0 %1\n\t" > + "mtsprg1 %2\n\t" > + "mtsprg2 %3\n\t" > + "mtsprg3 %4\n\t" > + : "=&r"(ofw_sprg0_save) > + : "r"(ofmsr[1]), > + "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > + else > #endif > + __asm __volatile("mtsprg1 %0\n\t" > + "mtsprg2 %1\n\t" > + "mtsprg3 %2\n\t" > + : > + : "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > } > > static __inline void > @@ -147,7 +148,8 @@ > * PCPU data cannot be used until this routine is called ! > */ > #ifndef __powerpc64__ > - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > + if (!(cpu_features & PPC_FEATURE_64)) > + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > #endif > } > #endif > > > The cross check code is code like the following > but should not be important outside my context: > > +if ((((uintptr_t) frame) & 0x3) != 0x0) { panic("trap: frame misaligned"); } // HACK > +if ((void*) frame < (void*) 0x1000) { panic("trap: frame too small"); } // HACK > > and: > > +if ((((uintptr_t) framep) & 0x3) != 0x0) { panic("powerpc_interrupt: framep misaligned"); } // HACK > +if ((void*) framep < (void*) 0x1000) { panic("powerpc_interrupt: framep too small"); } // HACK > > and: > > avoiding VM_PROT_EXECUTE on most kernel pages with > no code (when PPC_FEATURE_64 is present): > > struct pvo_entry *pvo, *oldpvo; > > pvo = alloc_pvo_entry(0); > +#if defined(AIM) && !defined(__powerpc64__) > + if (cpu_features & PPC_FEATURE_64) > + { > + if ( va < ((vm_offset_t)(etext+(PAGE_SIZE-1)) & ~PAGE_MASK) ) > + pvo->pvo_pte.prot = VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE; > + > + else if ( ((vm_offset_t)_GOT_START_ & ~PAGE_MASK) <= va > + && va < ((vm_offset_t)(_GOT_END_+(PAGE_SIZE-1)) & ~PAGE_MASK) > + ) > + pvo->pvo_pte.prot = VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE; > + > + else if ( va < (__endkernel & ~PAGE_MASK) ) > + pvo->pvo_pte.prot = VM_PROT_READ | VM_PROT_WRITE; > + > + else // Otherwise do as before the HACK: > + pvo->pvo_pte.prot = VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE; > + } > + else > +#endif > pvo->pvo_pte.prot = VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE; > pvo->pvo_pte.pa = (pa & ~ADDR_POFF) | moea64_calc_wimg(pa, ma); > pvo->pvo_vaddr |= PVO_WIRED; > > combined with: > > Index: /usr/src/sys/conf/ldscript.powerpc > =================================================================== > --- /usr/src/sys/conf/ldscript.powerpc (revision 324071) > +++ /usr/src/sys/conf/ldscript.powerpc (working copy) > @@ -24,6 +24,9 @@ > _etext = .; > PROVIDE (etext = .); > > + /* Force after this to start on a separate page from what is *before* _etext/etext */ > + . = ((. + 0x1000 - 1) & ~(0x1000 - 1)); > + > .interp : { *(.interp) } > .hash : { *(.hash) } > .dynsym : { *(.dynsym) } > > > As for the libkvm hacks to get raw memory dumps: > > Index: /usr/src/lib/libkvm/kvm_powerpc.c > =================================================================== > --- /usr/src/lib/libkvm/kvm_powerpc.c (revision 324071) > +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy) > @@ -209,6 +209,53 @@ > if (be32toh(vm->ph->p_paddr) == 0xffffffff) > return ((int)powerpc_va2off(kd, va, ofs)); > > + // HACK in something for what I observe in > + // a debug.minidump=0 vmcore.* for 32-bit powerpc > + // > + if ( be32toh(vm->ph->p_vaddr) == 0xffffffff > + && be32toh(vm->ph->p_paddr) == 0 > + && be16toh(vm->eh->e_phnum) == 1 > + ) { > + // Presumes p_memsz is either unsigned > + // 32-bit or is 64-bit, same for va . > + > + if (be32toh(vm->ph->p_memsz) <= va) > + return 0; // Like powerpc_va2off > + > + // If ofs was (signed) 32-bit there > + // would be a problem for sufficiently > + // large postive memsz's and va's > + // near the end --because of p_offset > + // and dmphdrsz causing overflow/wrapping > + // for some large va values. > + // Presumes 64-bit ofs for such cases. > + // Also presumes dmphdrsz+p_offset > + // is non-negative so that small > + // non-negative va values have no > + // problems with ofs going negative. > + > + *ofs = vm->dmphdrsz > + + be32toh(vm->ph->p_offset) > + + va; > + > + // The normal return value overflows/wraps > + // for p_memsz == 0x80000000u when va == 0 . > + // Avoid this by depending on calling code's > + // loop for sufficiently large cases. > + // This code presumes p_memsz/2 <= MAX_INT . > + // 32-bit powerpc FreeBSD does not allow > + // using more than 2 GiBytes of RAM but > + // does allow using 2 GiBytes on 64-bit > + // hardware. > + // > + if ( (int)be32toh(vm->ph->p_memsz) < 0 > + && va < be32toh(vm->ph->p_memsz)/2 > + ) > + return be32toh(vm->ph->p_memsz)/2; > + > + return be32toh(vm->ph->p_memsz) - va; > + } > + > _kvm_err(kd, kd->program, "Raw corefile not supported"); > return (0); > } > Index: /usr/src/lib/libkvm/kvm_private.c > =================================================================== > --- /usr/src/lib/libkvm/kvm_private.c (revision 324071) > +++ /usr/src/lib/libkvm/kvm_private.c (working copy) > @@ -128,7 +128,9 @@ > { > > return (kd->nlehdr.e_ident[EI_CLASS] == class && > - kd->nlehdr.e_type == ET_EXEC && > + ( kd->nlehdr.e_type == ET_EXEC || > + kd->nlehdr.e_type == ET_DYN > + ) && > kd->nlehdr.e_machine == machine); > } > > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Oct 7 10:24:37 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 735A3E34ACD for ; Sat, 7 Oct 2017 10:24:37 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id C30E775B2F for ; Sat, 7 Oct 2017 10:24:35 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 57FFFDF7DAB; Sat, 7 Oct 2017 12:21:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1507371711; bh=2k70hs5khRU9564oIfUiUTPIfVjFkSWgH8C6282j8ZI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BWDAJsStf8Ou5EoX66Er/k8UgtRE4S0U96q8Xiqx1Xgh78KrRECSmQ47o2Iu7QtH0 Tz9yGjhdWERwesFYaoSyJRcf83WAElabjPbhDvYzs7/uZ7s9G0VlcLcnocSTt9EgVT HgsGU5iW1qRpmLJdKSwZG0qKVWYLt5GPfvF/KjjA= Date: Sat, 7 Oct 2017 12:21:51 +0200 From: Roman Divacky To: Mark Millard Cc: Justin Hibbits , Warner Losh , FreeBSD Current Subject: Re: C++ in jemalloc Message-ID: <20171007102151.GA84155@vlakno.cz> References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Mailman-Approved-At: Sat, 07 Oct 2017 10:59:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 10:24:37 -0000 Answers inline. On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote: > Just a short top-post as this does not fit well with the > other material: > > I believe Roman only built his example program > with clang, not the world that the program was > being run under. I used a machine with gcc built world and compiled the test program using clang -stdlib=libstdc++ > The gcc 4.2.1 based code that is analogous to > __cxa_begin_catch (scratch register initialization) > in a clang based build world has the scratch > register CFI material and the same clang produced > a.out file works fine under such a system (simply > copied over and run). > > And that is why Roman's context did not SIGSEGV but > mine did: I used clang for the buildworld for > the world that was being used and so > __cxa_begin_catch was missing CFI information in > my build. > > In fact the a.out built by gcc 4.2.1 fails under > the clang based buildworld with the bad > __cxa_begin_catch . > > The only thing that matters is the system library > code involved, not which a.out (from which compiler). Ah. I see... Is it possible to isolate a small example that shows the missing CFI info from clang so that I can try to fix it without having to build world etc. ? It should be reasonably simple. > On 2017-Oct-7, at 2:54 AM, Mark Millard wrote: > > [The last part of my note has a dumb mistake, not > that it messes up the other evidence. I should have > dwarfdump'd not a.out but the code in the libraries, > such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I > made the same mistake initially back when Roman and > I were dealing with this long ago. Correcting it > again. . .] > > On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > > > [I'm separately listing backtrace information and related > > information from one of core dumps and going back through > > the details to see if they seem to be as they were back > > then. Read only if you care. It does look the same as I > > found back then if I remember right. I reach the same > > conclusion I reached back then anyway. I give evidence > > in the below.] > > > > On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > > > >> [I'm adding examples with output from clang -v since it explicitly shows > >> the path used for ld and such.] > >> > >> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: > >> > >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: > >>> > >>>> Just to clarify my not agreeing with Mark regarding EH on ppc64. > >>>> > >>>> Last time I tried to fix ppc64 exceptions handling as generated by clang > >>>> it turned out that simply using gnu ld from ports fixes the issue. > >>>> > >>>> For details see: > >>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html > >>> > >>> Unfortunately my experiments failed to confirm this. Repeating > >>> them now under head -r324071 and ports -r450478 : > >>> > >>> # more exception_test.cpp > >>> #include > >>> > >>> int main(void) > >>> { > >>> try { throw std::exception(); } > >>> catch (std::exception& e) {} > >>> return 0; > >>> } > >>> > >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >>> > >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >> > >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g exception_test.cpp > >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) > >> Target: powerpc64-unknown-freebsd12.0 > >> Thread model: posix > >> InstalledDir: /usr/bin > >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ exception_test.cpp > >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target powerpc64-unknown-freebsd12.0 > >> #include "..." search starts here: > >> #include <...> search starts here: > >> /usr/include/c++/v1 > >> /usr/lib/clang/5.0.0/include > >> /usr/include > >> End of search list. > >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > >> > >> # ./a.out > >> Segmentation fault (core dumped) > >> > >> > >>> # ls -lt /usr/local/powerpc64-freebsd/bin > >>> total 56704 > >>> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> ../../bin/powerpc64-freebsd-size > >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld > >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd > >>> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as > >>> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip > >>> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm > >>> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf > >>> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy > >>> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib > >>> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar > >>> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump > >>> > >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >> > >> # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 exception_test.cpp > >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) > >> Target: powerpc64-unknown-freebsd12.0 > >> Thread model: posix > >> InstalledDir: /usr/bin > >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj -disable-free -main-file-name exception_test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -O2 -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp > >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target powerpc64-unknown-freebsd12.0 > >> #include "..." search starts here: > >> #include <...> search starts here: > >> /usr/include/c++/v1 > >> /usr/lib/clang/5.0.0/include > >> /usr/include > >> End of search list. > >> "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-3ebf72.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > >> > >> # ./a.out > >> Segmentation fault (core dumped) > >> > >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++11 -g exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >>> > >>> > >>> # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ > >>> total 363584 > >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld > >>> -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd > >>> -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as > >>> -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip > >>> -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm > >>> -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf > >>> -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool > >>> -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy > >>> -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib > >>> -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar > >>> -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump > > > > [Note: I used /usr/libexec/gdb because /usr/local/bin/gdb > > core dumps for this. powerpc64 is an example of the > > devel/gdb port currently being worse than the system gdb > > in various cases.] > > > > # /usr/libexec/gdb a.out /var/crash/a.out.12775.core > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "powerpc64-marcel-freebsd"... > > Core was generated by `./a.out'. > > Program terminated with signal 11, Segmentation fault. > > Reading symbols from /usr/lib/libc++.so.1...Reading symbols from /usr/lib/debug//usr/lib/libc++.so.1.debug...done. > > done. > > . . . > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x0000000050530c20 in _Unwind_SetGR (context=, index=, val=1342447712) at unwind-dw2-fde.h:162 > > 162 { > > (gdb) bt > > #0 0x0000000050530c20 in _Unwind_SetGR (context=, index=, val=1342447712) at unwind-dw2-fde.h:162 > > #1 0x0000000050190194 in __gxx_personality_v0 (version=, actions=, exceptionClass=, exceptionObject=0x50042060, > > context=0xffffffffffffcc70) at /usr/src/contrib/libcxxrt/exception.cc:1203 > > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060, context=0xffffffffffffcc70) at unwind.inc:66 > > #3 0x0000000050531548 in _Unwind_RaiseException (exc=) at unwind.inc:135 > > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=, tinfo=, dest=) at /usr/src/contrib/libcxxrt/exception.cc:774 > > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > > #6 0x0000000010000ae8 in _start (argc=1342447624, argv=0x50042060, env=0xffffffffffffcc70, obj=, cleanup=, ps_strings=) > > at /usr/src/lib/csu/powerpc64/crt1.c:94 > > #7 0x0000000050017b70 in .text () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > > > > . . . > > > > __gxx_personality_v0 was trying to execute: > > > > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > > reinterpret_cast(exceptionObject)); > > > > That was part of the sequence: > > > > . . . > > _Unwind_SetIP(context, reinterpret_cast(action.landing_pad)); > > _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), > > reinterpret_cast(exceptionObject)); > > _Unwind_SetGR(context, __builtin_eh_return_data_regno(1), selector); > > > > return _URC_INSTALL_CONTEXT; > > > > > > So it died trying to use the CFA information for one of > > the scratch registers, the one used for the "exceptionObject". > > > > The details are: > > > > inline void > > _Unwind_SetGR (struct _Unwind_Context *context, int index, _Unwind_Word val) > > { > > int size; > > void *ptr; > > > > index = DWARF_REG_TO_UNWIND_COLUMN (index); > > gcc_assert (index < (int) sizeof(dwarf_reg_size_table)); > > size = dwarf_reg_size_table[index]; > > > > if (_Unwind_IsExtendedContext (context) && context->by_value[index]) > > { > > context->reg[index] = (void *) (_Unwind_Internal_Ptr) val; > > return; > > } > > > > ptr = context->reg[index]; > > > > if (size == sizeof(_Unwind_Ptr)) > > * (_Unwind_Ptr *) ptr = val; > > else > > { > > gcc_assert (size == sizeof(_Unwind_Word)); > > * (_Unwind_Word *) ptr = val; > > } > > } > > > > Note: DWARF_REG_TO_UNWIND_COLUMN leaves the index value > > unchanged for the value involved. I'll not provide the > > evidence here. > > > > Breakpoint 1, main () at exception_test.cpp:5 > > 5 try { throw std::exception(); } > > (gdb) br _Unwind_SetGR > > Breakpoint 2 at 0x50530bbc > > (gdb) c > > Continuing. > > > > Breakpoint 2, _Unwind_SetGR (context=0xffffffffffffcc30, index=3, val=1342447712) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > > 207 index = DWARF_REG_TO_UNWIND_COLUMN (index); > > Current language: auto; currently minimal > > (gdb) bt > > #0 _Unwind_SetGR (context=0xffffffffffffcc30, index=3, val=1342447712) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 > > #1 0x0000000050190194 in __gxx_personality_v0 (version=, actions=, exceptionClass=, exceptionObject=0x50042060, > > context=0xffffffffffffcc30) at /usr/src/contrib/libcxxrt/exception.cc:1203 > > #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060, context=0xffffffffffffcc30) at unwind.inc:66 > > #3 0x0000000050531548 in _Unwind_RaiseException (exc=) at unwind.inc:135 > > #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=, tinfo=, dest=) at /usr/src/contrib/libcxxrt/exception.cc:774 > > #5 0x0000000010000d74 in main () at exception_test.cpp:5 > > #6 0x0000000010000ae8 in _start (argc=1342447624, argv=0x50042060, env=0xffffffffffffcc30, obj=, cleanup=, ps_strings=) > > at /usr/src/lib/csu/powerpc64/crt1.c:94 > > #7 0x0000000050017b70 in .text () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > > (gdb) print *context > > $2 = {reg = 0xffffffffffffcc30, cfa = 0xffffffffffffd990, ra = 0x10000d78, lsda = 0x10000f74, bases = {tbase = 0x0, dbase = 0x0, func = 0x10000d30}, flags = 4611686018427387904, version = 0, > > args_size = 0, by_value = 0xffffffffffffd108 ""} > > (gdb) print dwarf_reg_size_table[3] > > $3 = 8 '\b' > > (gdb) print context->reg[3] > > $4 = (void *) 0x0 > > > > And there is the problem: lack of the value > > that is supposed to be available there: NULL > > instead. > > > > This traces back to. . . > > . . . (removed mistake) . . . > > Quoting an old note to Roman: > > The landing pad area includes the __cxa_being_catch and > __cxa_end_catch and the involved code from > /lib/libcxxrt.so.1 should have the scratch-register CFI > entries, not the above main code. > > So there was no point to my listing the CFI information > for main. > > End Quote. > > The below points out where there should have been > CFI information for the scratch registers, including > the failing r3 use. (Below is essentially my self- > correction text that I sent to Roman long ago.) > > # ldd a.out > a.out: > libc++.so.1 => /usr/lib/libc++.so.1 (0x5004e000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x5017b000) > libm.so.5 => /lib/libm.so.5 (0x501a2000) > libc.so.7 => /lib/libc.so.7 (0x501da000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x5052c000) > > The used scratch registers (of r3, r4, r5, r6) should > show up in: > > # dwarfdump -v -v -F /lib/libcxxrt.so.1 | egrep -i "\" > # > > but do not. > > In __cxa_begin_catch below note the code setting up r3-r5 > before the branch to __cxa_begin_catch+164 and that > __cxa_begin_catch+164 on is exit code that leaves > these scratch register alone. (The path skipping > __cxa_begin_catch+144 is similar for the issue.) > > __cxa_being_catch's CFI information should list the > r3, r4, and r5 scratch register usage but does not. > (Powerpc 32-bit has the same issue for the same > registers for its __cxa_begin_catch .) > > > (gdb) Dump of assembler code for function __cxa_begin_catch: > 0x000000005018ecc4 <__cxa_begin_catch+0>: mflr r0 > 0x000000005018ecc8 <__cxa_begin_catch+4>: std r0,16(r1) > 0x000000005018eccc <__cxa_begin_catch+8>: stdu r1,-144(r1) > 0x000000005018ecd0 <__cxa_begin_catch+12>: std r29,120(r1) > 0x000000005018ecd4 <__cxa_begin_catch+16>: std r30,128(r1) > 0x000000005018ecd8 <__cxa_begin_catch+20>: mr r29,r3 > 0x000000005018ecdc <__cxa_begin_catch+24>: bl 0x5018e634 <_ZL11thread_infov> > 0x000000005018ece0 <__cxa_begin_catch+28>: mr r30,r3 > 0x000000005018ece4 <__cxa_begin_catch+32>: lwz r3,48(r30) > 0x000000005018ece8 <__cxa_begin_catch+36>: addi r3,r3,-1 > 0x000000005018ecec <__cxa_begin_catch+40>: stw r3,48(r30) > 0x000000005018ecf0 <__cxa_begin_catch+44>: ld r3,0(r29) > 0x000000005018ecf4 <__cxa_begin_catch+48>: bl 0x50190210 <_ZL14isCXXExceptionm> > 0x000000005018ecf8 <__cxa_begin_catch+52>: cmpldi r3,0 > 0x000000005018ecfc <__cxa_begin_catch+56>: beq- 0x5018ed44 <__cxa_begin_catch+128> > 0x000000005018ed00 <__cxa_begin_catch+60>: mr r3,r29 > 0x000000005018ed04 <__cxa_begin_catch+64>: bl 0x5018f81c <_ZL20exceptionFromPointerPv> > 0x000000005018ed08 <__cxa_begin_catch+68>: lwz r4,48(r3) > 0x000000005018ed0c <__cxa_begin_catch+72>: cmplwi r4,0 > 0x000000005018ed10 <__cxa_begin_catch+76>: bne- 0x5018ed20 <__cxa_begin_catch+92> > 0x000000005018ed14 <__cxa_begin_catch+80>: ld r5,40(r30) > 0x000000005018ed18 <__cxa_begin_catch+84>: std r5,40(r3) > 0x000000005018ed1c <__cxa_begin_catch+88>: std r3,40(r30) > 0x000000005018ed20 <__cxa_begin_catch+92>: srawi r5,r4,31 > 0x000000005018ed24 <__cxa_begin_catch+96>: li r29,0 > 0x000000005018ed28 <__cxa_begin_catch+100>: add r4,r4,r5 > 0x000000005018ed2c <__cxa_begin_catch+104>: xor r4,r4,r5 > 0x000000005018ed30 <__cxa_begin_catch+108>: addi r4,r4,1 > 0x000000005018ed34 <__cxa_begin_catch+112>: stw r4,48(r3) > 0x000000005018ed38 <__cxa_begin_catch+116>: stw r29,32(r30) > 0x000000005018ed3c <__cxa_begin_catch+120>: ld r3,80(r3) > 0x000000005018ed40 <__cxa_begin_catch+124>: b 0x5018ed68 <__cxa_begin_catch+164> > 0x000000005018ed44 <__cxa_begin_catch+128>: ld r3,40(r30) > 0x000000005018ed48 <__cxa_begin_catch+132>: cmpldi r3,0 > 0x000000005018ed4c <__cxa_begin_catch+136>: beq- 0x5018ed58 <__cxa_begin_catch+148> > 0x000000005018ed50 <__cxa_begin_catch+140>: bl 0x50184480 <00000017.plt_call._ZSt9terminatev> > 0x000000005018ed54 <__cxa_begin_catch+144>: ld r2,40(r1) > 0x000000005018ed58 <__cxa_begin_catch+148>: addi r3,r29,32 > 0x000000005018ed5c <__cxa_begin_catch+152>: li r4,1 > 0x000000005018ed60 <__cxa_begin_catch+156>: std r29,40(r30) > 0x000000005018ed64 <__cxa_begin_catch+160>: stw r4,32(r30) > 0x000000005018ed68 <__cxa_begin_catch+164>: ld r30,128(r1) > 0x000000005018ed6c <__cxa_begin_catch+168>: ld r29,120(r1) > 0x000000005018ed70 <__cxa_begin_catch+172>: addi r1,r1,144 > 0x000000005018ed74 <__cxa_begin_catch+176>: ld r0,16(r1) > 0x000000005018ed78 <__cxa_begin_catch+180>: mtlr r0 > 0x000000005018ed7c <__cxa_begin_catch+184>: blr > 0x000000005018ed80 <__cxa_begin_catch+188>: .long 0x0 > 0x000000005018ed84 <__cxa_begin_catch+192>: .long 0x0 > 0x000000005018ed88 <__cxa_begin_catch+196>: .long 0x0 > End of assembler dump. > > > Sorry for the earlier mis-direction. > > > === > Mark Millard > markmi at dsl-only.net > > > > From owner-freebsd-current@freebsd.org Sat Oct 7 15:40:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82703E3AEFF for ; Sat, 7 Oct 2017 15:40:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 E1F897409A for ; Sat, 7 Oct 2017 15:40:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29345 invoked from network); 7 Oct 2017 15:40:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 15:40:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 11:40:06 -0400 (EDT) Received: (qmail 31464 invoked from network); 7 Oct 2017 15:40:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 15:40:06 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 01030EC8559; Sat, 7 Oct 2017 08:40:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: <20171007102151.GA84155@vlakno.cz> Date: Sat, 7 Oct 2017 08:40:05 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> <20171007102151.GA84155@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:40:09 -0000 On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote: > Answers inline. >=20 > On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote: >> Just a short top-post as this does not fit well with the >> other material: >>=20 >> I believe Roman only built his example program >> with clang, not the world that the program was >> being run under. >=20 > I used a machine with gcc built world and compiled the test program = using=20 >=20 > clang -stdlib=3Dlibstdc++ There is (and was) no libstdc++ in my context. So I'd have to build a clang based world that had it first. Note: Nothing that I've been saying indicates if what you found earlier was a separate issue as far as I know. >> The gcc 4.2.1 based code that is analogous to >> __cxa_begin_catch (scratch register initialization) >> in a clang based build world has the scratch >> register CFI material and the same clang produced >> a.out file works fine under such a system (simply >> copied over and run). >>=20 >> And that is why Roman's context did not SIGSEGV but >> mine did: I used clang for the buildworld for >> the world that was being used and so >> __cxa_begin_catch was missing CFI information in >> my build. >>=20 >> In fact the a.out built by gcc 4.2.1 fails under >> the clang based buildworld with the bad >> __cxa_begin_catch . >>=20 >> The only thing that matters is the system library >> code involved, not which a.out (from which compiler). >=20 > Ah. I see... Is it possible to isolate a small example > that shows the missing CFI info from clang so that I can > try to fix it without having to build world etc. ? >=20 > It should be reasonably simple. The following (using lang/gcc7 as an example) in a clang-built world also gets a SIGSEGV: # env C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++7 -std=3Dc++11 = -nostdinc++ -L/usr/lib -g -O2 exception_test.cpp # ldd a.out a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x5004f000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5017c000) libm.so.5 =3D> /lib/libm.so.5 (0x501a3000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501db000) libc.so.7 =3D> /lib/libc.so.7 (0x50200000) # ./a.out Segmentation fault (core dumped) #0 0x00000000501dfc20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342451808) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x00000000501dfc20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342451808) at = unwind-dw2-fde.h:162 #1 0x0000000050191194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50043060,=20 context=3D0xffffffffffffcc80) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x00000000501e0a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50043060,= context=3D0xffffffffffffcc80) at unwind.inc:66 #3 0x00000000501e0548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x00000000501904f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000898 in ?? () compared to system-clang's: #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc60) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc60) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000d74 in main () at exception_test.cpp:5 #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc60, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Current language: auto; currently minimal The code generation involved is tied to (driven by) the use of builtins, not just normal C/C++ code. Inlining is also mixed in. There could be more wrong than I've noticed. At some point comparing the dwarfdump output for gcc and clang for the same "interesting" source(s) being compiled would be appropriate, looking for mismatches that are not equivalent. (Unfortunately equivalence need not be a trivial judgment to make since CFI is a programming language of its own and the code being described is not identical, possibly inlined differently even.) So I'm building based on devel/powerpc64-xtoolchain-gcc using WITH_LIBCPLUSPLUS=3D to compare against. (I've not done a powerpc64-xtoolchain-gcc based build in a long time. Hopefully it still builds to completion.) It is far enough along now to have built a libcxxrt.so.1 so. . . But I need sleep. (It is well after 8am here.) All I'm managing to do is confuse myself at this point. I may have been wrong about where the scratch register initialization is inside the library, I'm not sure. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 7 20:34:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77EDFE41CCC for ; Sat, 7 Oct 2017 20:34:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0062.outbound.protection.outlook.com [104.47.37.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D47671AB3; Sat, 7 Oct 2017 20:34:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM (52.132.78.18) by YQXPR0101MB1013.CANPRD01.PROD.OUTLOOK.COM (52.132.78.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 20:34:06 +0000 Received: from YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5]) by YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM ([fe80::7548:a72a:e054:70d5%13]) with mapi id 15.20.0077.011; Sat, 7 Oct 2017 20:34:06 +0000 From: Rick Macklem To: Ian Lepore , "freebsd-current@freebsd.org" Subject: Re: RFC how to use kernel procs/threads efficiently Thread-Topic: RFC how to use kernel procs/threads efficiently Thread-Index: AQHTPtSLQYujf8n5KEGHc2bjAF54kqLXMAcAgAGndEo= Date: Sat, 7 Oct 2017 20:34:06 +0000 Message-ID: References: , <1507317060.86205.268.camel@freebsd.org> In-Reply-To: <1507317060.86205.268.camel@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1013; 6:c7azBMsukv4rIUXksMaUYWS/YPHbHUYdmF4mmicK4XdTi93s3MIVaZ7XnmxmgL3LAbXoLrAr8gl+/FpusOaY4C32X68iF0a48ZRJqBXpUL91AIBzo3S8ozC0OQ31tn0gE0jF1wjFl41N3lZvFlLImizKfOC+ZWvL7h2Z7kgOSjNbJZTVWisK9BFK+pWNvbE0khIywOjb5gxKXPU11aYDL7ma1lKPU8GxMeqLf3BF17URb/eJkrA5ZM+p0a8PP1S1cdE1o+z/++FGDwqiF3Z/Q2C/DlDTovW2h6uzXy+1A3nVhuxhP52M7vrNJnHltonztht/EVAHbr3EoFCkl3eOPg==; 5:QyHAGkG/4WCsbROmsCTaiqK4XcwgUXGQcvv8fa8lXKI5EV7WB5qPwJiFT5ERTToUcSv0DgrbveSsryn2dW1q+n2Op7EIO6tNRwuEzyRywCuKT3bcMlNVAXiQVsRP/QXnm+ajNHNXPDAa4wVcX/GSQQ==; 24:n7lC1cEdBVwNo94habGKSh+jp7p9UFcQks+OempSqcgT5DON5eGkS+lPtP2NgRbYaED7tECF4//zIsDuoiy867xsV8CCn3ZBY3xknPhKONA=; 7:q1v2O7zoM9nqE36gDu23JPXV8+lLKrV7l8FfrAGlm60mnSIKTO3PUVVOdqqZ31n2KJ5UUEFLYcmx5wkSoR9ZROY38PqLh2IaOBeB0aa6k3Vf5L4G5BOvOsOKCNcyMpx1DO3Xt4wdq+TAPi24XISnWVB4nsUh76vuKpLq8u3stYRuUStyEEDTySTD4q/sqyK03Dh4DFVVVecYI2+cGaXnNbRFfYOlDlHD0bkvl8qtWyI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fcd69c7a-efd0-4925-cc75-08d50dc2c190 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YQXPR0101MB1013; x-ms-traffictypediagnostic: YQXPR0101MB1013: x-exchange-antispam-report-test: UriScan:(158342451672863)(5213294742642); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQXPR0101MB1013; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQXPR0101MB1013; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(377424004)(199003)(24454002)(51914003)(5660300001)(68736007)(97736004)(106356001)(86362001)(74316002)(786003)(8936002)(316002)(450100002)(81166006)(229853002)(6436002)(14454004)(76176999)(6506006)(7696004)(102836003)(110136005)(74482002)(55016002)(6246003)(25786009)(305945005)(2906002)(189998001)(101416001)(2950100002)(478600001)(8676002)(2501003)(81156014)(50986999)(53936002)(3280700002)(9686003)(3660700001)(54356999)(2900100001)(33656002)(105586002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR0101MB1013; H:YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 20:34:06.4164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1013 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 20:34:09 -0000 Ian Lepore wrote: >On Fri, 2017-10-06 at 19:02 +0000, Rick Macklem wrote: >> Hi, >> >> I have now dropped the client side of Flexible File Layout for pNFS into= head >> and I believe it is basically working. >> Currently when talking to mirrored DS servers, it does the Write and Com= mit >> RPCs to the mirrors serially. This works, but is inefficient w.r.t. elap= sed to to >> completion. >> >> To do them concurrently, I need separate kernel processes/threads to do = them. >> I can think of two ways to do this: >> 1 - The code that I have running in projects/pnfs-planb-server for the p= NFS server >> side does a kproc_create() to create a kernel process that does th= e RPC and >> then krpc_exit()s. >> - This was easy to code and works. However, I am concerned that th= ere is >> going to be excessive overheads from doing all the kproc_create(= )s and >> kproc_exit()s? >> Anyone know if these calls will result in large overheads? >> 2 - I haven't coded this, but the other way I can think of to do this is= to >> create a pool of threads (kthread_create() is sufficient in this c= ase, I >> think?) and then hand each RPC to an available thread so it can do= the RPC. >> - Other than a little more complex coding, the main issue I see wi= th this one >> is "How many threads and when to create more/less of them.". >> >> Anyhow, any comments w.r.t. the merits of either of the above approaches >> (or a suggestion of other ways to do this) would be appreciated, rick > >taskqueue(9) is an existing mechanism to enqueue functions to execute >asynch using a pool of threads, but it doesn't answer the scalability >questions. In fact it may make them harder, inasmuch as I don't think >there's a mechanism to dynamically adjust the number of threads after >first calling taskqueue_start_threads(). Hmm, yes. Thanks for the pointer. I hadn't read "man taskqueue" until now. The kernel RPC doesn't use this and I suspect that it is because of what yo= u said w.r.t. dynamically adjusting the # of threads. However, it does save "hand coding" the queues for #2 and I'm lazy (plus don't believe reinventing the wheel is the best plan). I think I will try using taskqueue and just have a sysctl for #of-threads. (Actually most of the code ends up the same, because basically they all end up with a function with a single argument that does the RPC. The only difference is what call starts the RPC.) Anyone else have comments? rick=