From owner-freebsd-arch@freebsd.org Wed Oct 17 09:48:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B09410CFD21; Wed, 17 Oct 2018 09:48:40 +0000 (UTC) (envelope-from admin@npo-lencor.ru) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9503579917; Wed, 17 Oct 2018 09:48:39 +0000 (UTC) (envelope-from admin@npo-lencor.ru) Received: from mxback20j.mail.yandex.net (mxback20j.mail.yandex.net [IPv6:2a02:6b8:0:1619::114]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 45035186439; Wed, 17 Oct 2018 12:48:28 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback20j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id PYJa1AcOGS-mS6uA48u; Wed, 17 Oct 2018 12:48:28 +0300 Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Fpzm3Rs9h3-mRjGQMce; Wed, 17 Oct 2018 12:48:27 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: Brooks Davis References: <20181003210516.GA71565@spindle.one-eyed-alien.net> Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org, freebsd-fcp@freebsd.org, freebsd-stable@freebsd.org From: Nikita Druba Message-ID: Date: Wed, 17 Oct 2018 12:48:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181003210516.GA71565@spindle.one-eyed-alien.net> Content-Language: ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 09:48:40 -0000 04.10.2018 0:05, Brooks Davis пишет: >>>> Please direct replies to freebsd-arch <<< > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > and remove them in FreeBSD 13 to reduce the burden of maintaining and > improving the network stack. We have discussed this within the > core team and intend to move forward as proposed. We are solictiting > feedback on the list of drivers to be excepted from removal. > > The current list of drivers slated for REMOVAL is: > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe > > The current list of drivers that will STAY in the tree is: > > dc, ffec, fxpl, hme, le, sis, vr, xl > > The criteria for exception are: > - Popular in applications where it is likely to be deployed beyond the > support lifetime of FreeBSD 12 (late 2023). > - 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usable. > - Ported to use iflib (reducing future maintenance cost.) > > Please reply to this message with nominations to the exception list. > > The full FCP-0101 is included below. > > -- Brooks > > --- > authors: Brooks Davis > state: feedback > --- > > # FCP 101: Deprecation and removal of 10/100 Ethernet drivers > > Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before > FreeBSD 13. > > ## Problem Statement > > Each network driver creates drag for the project as we attempt to > improve the network stack or provide new features such as expanded > 32-bit compatibility. For example, the author has edited every single > NIC driver more than once in the past year to update management (`ioctl`) > interfaces. We could improve this situation by converting drivers to > iflib, but each additional driver takes work. > > 10 and 100 megabit Ethernet drivers are largely irrelevant today > and we have a significant number of them in the tree. The ones that > are no longer used and/or are not known to be working need to be > removed due to the significant ongoing 'tax' on new development. > > For at least a decade, most systems (including small embedded > systems) have shipped with gigabit Ethernet devices and virtual > machines commonly emulate popular gigabit devices. We wish to > retain support for popular physical and virtual devices while > removing support for uncommon ones. With a few exceptions these > drivers are unlikely to be used by our user base by the time FreeBSD > 12 is obsolete (approximately 2024). > > ## Proposed Solution > > We propose to deprecate devices which are not sufficiently popular. This > will entail: > - (October 2018) Send this list to freebsd-net and freebsd-stable. > - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and > attach routines for each device to be removed and merge those changes > to FreeBSD 12. > - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind > freebsd-net and freebsd-stable users of pending deletion. > - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated > devices. > > Through out this process, solicit feedback on additions to the exception > list and update this document as required. For a device to be placed on > the exception list the device must meet one of the following criteria: > - Popular in applications where it is likely to be deployed beyond the > support lifetime of FreeBSD 12 (late 2023). > - 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usable. > - Ported to use iflib (reducing future maintenance cost.) > > ### Exceptions to removal > > Device | Reason > -------|------------------------------------------------- > ffec | Onboard Ethernet for Vybrid arm7 boards > fxp | Popular device long recommended by the project. > dc | Popular device for CardBus card. > hme | Built in interface on many supported sparc64 platforms. > le | Emulated by QEMU, alternatives don't yet work for mips64. > sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641. > vr | Soekris Engineering net5501, some Asus motherboards. > xl | Popular device for CardBus card. > > Note: USB devices have been excluded from consideration in this round. > > ### Device to be removed > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe > > ## Final Disposition > > TBD Hello! My servers use rl and bfe devices from deprecated list. Also I have some ed devices for replacement failed adapters. Also I can try do convertion to iflib for bfe, rl and ed devices, but still no one not showed good example driver that has already been converted... P.S. So late, because I was away and just returned. From owner-freebsd-arch@freebsd.org Wed Oct 17 17:51:24 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16A6210DB231; Wed, 17 Oct 2018 17:51:24 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) (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 A57FC8BE64; Wed, 17 Oct 2018 17:51:23 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e34:ec17:2560:232:36ff:fe5c:3a87]) by smtp5-g21.free.fr (Postfix) with ESMTPS id AE8965FFC6; Wed, 17 Oct 2018 19:51:06 +0200 (CEST) Received: from gramr.alkumuna.eu ([IPv6:2a01:e34:ec17:2560:62a4:4cff:fe54:b212]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.15.2/8.15.2) with ESMTPSA id w9HHp4xR034085 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 17 Oct 2018 19:51:06 +0200 (CEST) (envelope-from mazhe@alkumuna.eu) Date: Wed, 17 Oct 2018 19:51:04 +0200 From: Matthieu Volat To: Brooks Davis Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org, freebsd-fcp@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181017195104.1e2ac9ad@gramr.alkumuna.eu> In-Reply-To: <20181003210516.GA71565@spindle.one-eyed-alien.net> References: <20181003210516.GA71565@spindle.one-eyed-alien.net> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/0hqv/cPb1GSOz.8MvQCcs1r"; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkumuna.eu; s=default; t=1539798666; bh=wFmX6dcFt3m4xJwy5KmjAZxzxGrI2FA0YEQHxoe/Rgk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Type; b=M17lKLU6DOQ63cEKclHL0wCBFetHoz1nOtJlLvvlhYAX1dJbP6U8YLi5hv6SpwFTwePnVMyeeVITGAtwCE8MzAFutjFm9iPw3CKyGJ+Sdl7y9SxMWtJWfb8Va9KUy4qpz8BbzpTYq5VcK8mssytUHNo2SCB4iY61bozko69z+Og= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 17:51:24 -0000 --Sig_/0hqv/cPb1GSOz.8MvQCcs1r Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Oct 2018 21:05:16 +0000 Brooks Davis wrote: > >>> Please direct replies to freebsd-arch <<< =20 >=20 > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > and remove them in FreeBSD 13 to reduce the burden of maintaining and > improving the network stack. We have discussed this within the > core team and intend to move forward as proposed. We are solictiting > feedback on the list of drivers to be excepted from removal. >=20 > The current list of drivers slated for REMOVAL is: >=20 > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe >=20 > The current list of drivers that will STAY in the tree is: >=20 > dc, ffec, fxpl, hme, le, sis, vr, xl >=20 > The criteria for exception are: > - Popular in applications where it is likely to be deployed beyond the > support lifetime of FreeBSD 12 (late 2023). > - 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usabl= e. > - Ported to use iflib (reducing future maintenance cost.) >=20 > Please reply to this message with nominations to the exception list. >=20 > The full FCP-0101 is included below. >=20 > -- Brooks >=20 > --- > authors: Brooks Davis > state: feedback > --- >=20 > # FCP 101: Deprecation and removal of 10/100 Ethernet drivers >=20 > Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before > FreeBSD 13. >=20 > ## Problem Statement >=20 > Each network driver creates drag for the project as we attempt to > improve the network stack or provide new features such as expanded > 32-bit compatibility. For example, the author has edited every single > NIC driver more than once in the past year to update management (`ioctl`) > interfaces. We could improve this situation by converting drivers to > iflib, but each additional driver takes work. >=20 > 10 and 100 megabit Ethernet drivers are largely irrelevant today > and we have a significant number of them in the tree. The ones that > are no longer used and/or are not known to be working need to be > removed due to the significant ongoing 'tax' on new development. >=20 > For at least a decade, most systems (including small embedded > systems) have shipped with gigabit Ethernet devices and virtual > machines commonly emulate popular gigabit devices. We wish to > retain support for popular physical and virtual devices while > removing support for uncommon ones. With a few exceptions these > drivers are unlikely to be used by our user base by the time FreeBSD > 12 is obsolete (approximately 2024). >=20 > ## Proposed Solution >=20 > We propose to deprecate devices which are not sufficiently popular. This > will entail: > - (October 2018) Send this list to freebsd-net and freebsd-stable. > - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and > attach routines for each device to be removed and merge those changes > to FreeBSD 12. > - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind > freebsd-net and freebsd-stable users of pending deletion. > - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete depreca= ted > devices. >=20 > Through out this process, solicit feedback on additions to the exception > list and update this document as required. For a device to be placed on > the exception list the device must meet one of the following criteria: > - Popular in applications where it is likely to be deployed beyond the > support lifetime of FreeBSD 12 (late 2023). > - 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usabl= e. > - Ported to use iflib (reducing future maintenance cost.) >=20 > ### Exceptions to removal >=20 > Device | Reason > -------|------------------------------------------------- > ffec | Onboard Ethernet for Vybrid arm7 boards > fxp | Popular device long recommended by the project. > dc | Popular device for CardBus card. > hme | Built in interface on many supported sparc64 platforms. > le | Emulated by QEMU, alternatives don't yet work for mips64. > sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641. > vr | Soekris Engineering net5501, some Asus motherboards. > xl | Popular device for CardBus card. >=20 > Note: USB devices have been excluded from consideration in this round. >=20 > ### Device to be removed >=20 > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe >=20 > ## Final Disposition >=20 > TBD Would it be possible to set a wiki page/section in 12 that display the curr= ent status of removal of those devices? That might be easier for people to = look at their hardware actual state rather than try to trace every answer t= o this thread... Thanks a lot! --Sig_/0hqv/cPb1GSOz.8MvQCcs1r Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1xv/SVkem9252haa3yo2fFz8JX4FAlvHdogACgkQ3yo2fFz8 JX66RxAAhQfYTj4ff8KIG0GNnNkuKaui8zOcbSanmnjIQIqkzVCHQy5lZ7lnDgX2 NBV5wCrgQu5tvdjJ9du36DSmFvodgsxg5t5PFfBwcMKXB+LgkOjDLBBy3OwUMgbv GRNbGWU32RZMlBRYmEXe+6LgVtaRIQwQgn9bW64iOxKDJE0nZsFXnVXr7CbpDqOt RUUAMMiqI2my+8Fsdr1o44Hc8eFM/WOH9YPw8KTYIN8mFkqNJdobRWabTo9qY+Iw HAlgGzEhfKP1UYflq84U6yePp5/WAVjOEeuHbAa3u5lMkzN48QzvRbzoVTG01Ogw 6BjKmz8UXr6TWAQweswh9WW0dVxFHTKvI2VeMD6VtlRulZiUakI2ttJrAFuUgYgG ZfK1LD86LQ9a+QTxpiqNslMbeQY2tMK9OELRvBklahjCHjevd419o+e/WvmVrcTo E+cZJLpDXt4QgmWbNmACl6oyKIpAZt5+8PhHbUONfmcJXKUjB3hwBFhCXKpv7a7R L5uQgEzpi6spwz3G9eu7bZPPqsChnrANiH3gcQPRk8099nFLnhV1nbF3z6WdbwR+ ZeATzpidYo+Y0+j2PZCfGpGkazNt6RwsAvpK9WkAjxhqLSt6vn1b50c4zUfk0Gpl cJrdD1Fdds/FGBJMg7q6hOX8j/AhhHIPzLcv/RACFkopQhSwSwI= =IFD0 -----END PGP SIGNATURE----- --Sig_/0hqv/cPb1GSOz.8MvQCcs1r-- From owner-freebsd-arch@freebsd.org Wed Oct 17 18:28:01 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A882210DC2BB for ; Wed, 17 Oct 2018 18:28:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40E1E8D254 for ; Wed, 17 Oct 2018 18:28:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92c.google.com with SMTP id b3so5146675uak.3 for ; Wed, 17 Oct 2018 11:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M9hEbrf15LkYlp7t4sEl2Q+Dv8RDUFkQP+/Fvj0y7/w=; b=fpZC5pLOTcWrGGO3L9EvwLHpiWd01xlBbcoMw/OMmLwOo0125N/EhZ8CDWZwMnX1u0 RwXLNlB9NSTWrBNPknFske5aghnEk7qOsLLjq8Q3QVb2YmmaNCiuWkjVIFFjY9pGZjhq PDYk4GXSO2wZCWsd7Hx0WjcBeMDY/tgHZSpZ7zuOHqKgalI5DzP1JaAKe30rFEjHkSJU m0fQ6grEH9Jabhtoz3EUnSB227OfbMtLdIQjjGqHTnBGpKUQFYhRZXqvOzAVKqthdvHL B4D1c8IkQZ0Z7ZEJ1L/3Xtnc8Mq1+tJfbcr9rj4UKi09VQ+ucOg1q/toMVoWYp225Zt4 CwAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M9hEbrf15LkYlp7t4sEl2Q+Dv8RDUFkQP+/Fvj0y7/w=; b=Htax4wYiOVEl4JYMd3YGvzd0iXUaAXOd7IOJqDhXP3D/+LAEeGYWQoFOAAI+4D5A8O tNreM1uliWrbXMZNOrM5AcrkIs3Apfa3SreVhveYohYu53mKca2Akd2Qbh4WQPbA60Nw hj1/B0vxj9yCVZrkhUZhRuUzKj9m9jOCy7R8dDyFmhzUKk3JUq8dBk22m6ISrwE+3F7s 3dwGs/tgz5I8bHgiMlWCxhmb9HWaBR5fUyV9y5yejB1eL5BO7irB7PQOeavs3DO84Z4h 6nLWomkPQS59X0nVGdwsrg7KqAz0+PKv0MNAX76QiW7xL/Z3bZmdGXnZkk8kMtXkoIXe BCzA== X-Gm-Message-State: ABuFfogpYSwG9gj9kYb6ly9mXP884QzpKrXcw6UXr/e/UNFFc1wBDLV2 cyA4w3CKyL14aqzFJW2ww6fnsNFNsjFmEbGPmJNaeA== X-Google-Smtp-Source: ACcGV60XwfhtxdH8UUxrCT0aw2Km1uw4fp7VTy3pFy1KC0pB6u9zBilJVlx7tkEfwduEsYCbNExuHLoIr4p+HrynD/s= X-Received: by 2002:ab0:a97:: with SMTP id d23mr11804375uak.39.1539800880318; Wed, 17 Oct 2018 11:28:00 -0700 (PDT) MIME-Version: 1.0 References: <20181003210516.GA71565@spindle.one-eyed-alien.net> <20181017195104.1e2ac9ad@gramr.alkumuna.eu> In-Reply-To: <20181017195104.1e2ac9ad@gramr.alkumuna.eu> From: Warner Losh Date: Wed, 17 Oct 2018 12:27:48 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: mazhe@alkumuna.eu Cc: Brooks Davis , FreeBSD Net , freebsd-fcp@freebsd.org, FreeBSD-STABLE Mailing List , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:28:01 -0000 On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat wrote: > Would it be possible to set a wiki page/section in 12 that display the > current status of removal of those devices? That might be easier for people > to look at their hardware actual state rather than try to trace every > answer to this thread... > The FCP is being updated and will be uploaded when that's done. At this point, it seems that we have all the data to make the right decisions, at least to tag the drivers deprecated for the 12.0 release when I'm sure will get us additional data. Warner From owner-freebsd-arch@freebsd.org Wed Oct 17 19:46:02 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC13010DDA02; Wed, 17 Oct 2018 19:46:01 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) (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 5CDD08F3EB; Wed, 17 Oct 2018 19:46:01 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e34:ec17:2560:232:36ff:fe5c:3a87]) by smtp5-g21.free.fr (Postfix) with ESMTPS id 647275FF20; Wed, 17 Oct 2018 21:45:47 +0200 (CEST) Received: from gramr.alkumuna.eu ([IPv6:2a01:e34:ec17:2560:62a4:4cff:fe54:b212]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.15.2/8.15.2) with ESMTPSA id w9HJjkwR035124 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 17 Oct 2018 21:45:46 +0200 (CEST) (envelope-from mazhe@alkumuna.eu) Date: Wed, 17 Oct 2018 21:45:37 +0200 From: Matthieu Volat To: Warner Losh Cc: Brooks Davis , FreeBSD Net , freebsd-fcp@freebsd.org, FreeBSD-STABLE Mailing List , "freebsd-arch@freebsd.org" Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181017214537.4b500803@gramr.alkumuna.eu> In-Reply-To: References: <20181003210516.GA71565@spindle.one-eyed-alien.net> <20181017195104.1e2ac9ad@gramr.alkumuna.eu> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/RbvRQFNInMg47Kk6IqBHhYY"; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkumuna.eu; s=default; t=1539805547; bh=8smVUEi43Mjri2veIgEUmwlqlNLRIosaweIGYgTtvY0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Type; b=aZLjaJASz4iMwJWSpA+OwsPgfQR62EluORRGNXpkmmjUk+pPCGyZw9zQ8BZf53DC2Xo0o2fSI+xotySpX/A50GD2RoKOjsCXlURy3jFwIqXZTbCCEvm/RjDgidkkDQ+JzWLRLkSG2PVqhtQUYLx4xTQ0iY0a4CVBcCwqyqkrYmw= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 19:46:02 -0000 --Sig_/RbvRQFNInMg47Kk6IqBHhYY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 17 Oct 2018 12:27:48 -0600 Warner Losh wrote: > On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat wrote: >=20 > > Would it be possible to set a wiki page/section in 12 that display the > > current status of removal of those devices? That might be easier for pe= ople > > to look at their hardware actual state rather than try to trace every > > answer to this thread... > > =20 >=20 > The FCP is being updated and will be uploaded when that's done. At > this point, it seems that we have all the data to make the right decision= s, > at least to tag the drivers deprecated for the 12.0 release when I'm sure > will get us additional data. >=20 > Warner Thanks for the info! --Sig_/RbvRQFNInMg47Kk6IqBHhYY Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1xv/SVkem9252haa3yo2fFz8JX4FAlvHkWcACgkQ3yo2fFz8 JX4uQQ//W2Am4ExBIaEeQYxNHDJ1rqOgxp92AFF/XH8KaOd274Mu8q/XC0kY0h3t is6zyTEJYE+Q3qzo1prQKxg+3uCEy+qKVG2cCVxhMf6gORoxMGmx4bigt7y3ScCP ehswzzh4LuvSqLA3zpH6OFmkdBfQ20wdA6qz1yR3qBDfMANcQ+OF+cMEPeCHdkZL QmCWZuHBBmiH+5CSI/zHN22u18aLvA/O/hMvwyjiM7EOxUp7Fej06NTgq6ZjVK8m 7wLEDIRPXiJCuETpV4/GeI6N80nmRE3B3WM6VG6MebTdtn8eDgFw3nbOWrWkGBSz ZtXwqeHzAbUXEXReg4OYEWt5oBDYxeCDFrZbQZSrljqDZqkBz+AadtVhl6g/3eZv w005+a7FjPdSerTrkg/G6zHeYrjJ9wIM7sFLBKmc9Dik0Xf8wrxPkvV5CmHwNZOZ 3sR1LIZ4FFFe/XseP89ksEibion9yQ7qS78wFqYQdoSNMltfNzINcT3cB63dedhl /jcwbQuVaZIJyxDBW/sfjpYkkYwttoXRKWtKUPfQz9PVFx4eaOjjOy2lvAj4WySA iPCoyE5lkGVG+Sfi/Wp0aahphEpJvHRqRhRSml7PKApBJuDpoE/4XfrLJK0NZY/S VzhBayVet0AcpOEAAav+s6dsm9c9P/rUByexfKFYVkgNV0/z5Mg= =liTm -----END PGP SIGNATURE----- --Sig_/RbvRQFNInMg47Kk6IqBHhYY-- From owner-freebsd-arch@freebsd.org Wed Oct 17 20:25:50 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03EDD10DE807 for ; Wed, 17 Oct 2018 20:25:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 093AC905D6 for ; Wed, 17 Oct 2018 20:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .17zpVUVM1mNnfw6qZnnlw061.Segc8FdcVUgNsvTmB9z6anzaXPsRxzu.xUlWG XoykGuRCrwNL0IpO90jz27_P3TFPN9lLo7HRFoBWQVpXmz7Yd6WfYkXvtjCexuDIzNKyUW0ucnkO OBAnbi4xXmqsDGTcLVfe4lc7CW90AyQPvGnVrxJGSVCQxTSBKX2j7723LSPb5dBOcF0bi7vHs7x2 dD6KRV.mrt8tR.m6ki7PMkCWqzyOUIt_wXUUslaUcpE5aGbIJS92M.CXPybvCePGE0646iFSu_ka giF0dGnTpUD5fw6Hi.6i1kP4rPBx7ZJeRxLpS4cBgdNW3iciKzzDmapspgPWsP0CHn.9jqVN9JKB 64Vv3xWglFOOvTnYEQUgnV_LGHm9SFFWBCEGjI.1Vqjl5tYnzDq816F0FngxTJqbK_Bx9eOHha1e 2tdJ_PIJNj6V3pxEsDQZ12D8E2HDuF7Ix2E8RkTMPHDVOB2R9rMQXWRaw9jxJECUUAuc7Ul27iYG plKsEYS2L_bLTdVORUnPFDqUfx6XHJ9aXvLW2uJRe76pc6MKxevZnIxACvEiB9tQBQIKsZFQswJo 3bRnmyvPRzzyVwP0he80jLvT4MXIe6Fsg2GTyO4fiYolX07fig1KnIZYq27HhbxlJC_P4k1._FlZ L0HtMQTHGGr9ggWvww7w7mYe0ecyEGxq4Q8moct1WsQWhrOf4rxGCLIfZWnu75P5MGvLVAvkVNCO DpSa01D8nx44xnRoMQA1gpMuW5G2_OUbLLRLeKUfKyEeysslm4fSmF__JtdzYKXN9QnJ6YWfgB1C 9Ea1mApJvKPxEqbViksKSxu7ZzTSUlOXBX4sXkgzBIVEGshktXq2v644DcxnIUzfdDGLia6WS_zw aZhT9rj8cjy48hIFaa7YlSjRQWLT938oSOcdFNuRkv2KgHIudc1o5mXC4Q6Eh.sp6nNxWIzboF2x CLPkdN8PcPbSfJpl.GfEXSE4Sz3IhNfLGXLQzk6UG9AMiopmJFbsZsDW7oHJSaRwtPZT.uKAjfBy jgtyAU_d4.ohptH4OsDwIYIdQbRjLTU9gEoGmIIucszgdt0YlN6oYYz6en_sMqVzPbMeowXQX9iV LMhA3zBqH9RSen_4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Oct 2018 20:25:42 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80e922adb91863636bdf56988756cc64; Wed, 17 Oct 2018 20:25:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) Message-Id: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Wed, 17 Oct 2018 13:25:39 -0700 Cc: FreeBSD PowerPC ML To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 20:25:50 -0000 [This summarizes other results without the code and debugger evidence and such from my recent explorations. It should be much easier to follow than my exploration reports.] Documents like DWARF5.pdf document the "row" vs. Location information for Call Frame Information as (also used for .eh_frame like materials for C++ exception handling): (CFA: Cannonical Frame Address) QUOTE ("Structure of Call Frame Information") LOC CFA R0 R1...RN L0 L1 ... LN END QUOTE Note that the CFA is conceptually one of the registers in each row, even though it is not a machine register but a way to calculate the conceptual register's value from machine registers. The information for the machine registers are typically based on the earlier CFA value (from the same row!). Absent a correct CFA cell in a row, most potential use of that row is likely messed up. One way CFA is found is by adding an offset to the value of a machine register for the range in question, Ln up to L(n+1) [or based on the end of the overall range for the last Ln]. I will use that for illustration because there are examples of this in my testing. /lib/libgcc_s.so.1 does not implement this fully for some DW_CFA_* operations: QUOTE (note the "every register" reference, so including CFA) DW_CFA_remember_state The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. DW_CFA_restore_state The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. END QUOTE In other words: push and pop a complete row, not just machine registers information from the row. For example, the the "cfa_offset" for computing the CFA value from from a register is not saved and restored. Nor is which register the offset is based on. (This can vary, though not in my examples.) In general the CFA cell is not saved and restored, what ever its contents. So any compiler that produces code depending on DW_CFA_remember_state and DW_CFA_restore_state for .eh_frame like material ends up with C++ exception handling messed up when the DW_CFA_restore_state should change the CFA to a=20 non-default one (from the prior DW_CFA_remember_state). This prevents reliable use of throwing C++ exceptions when building via the likes of devel/powerpc64-gcc or lang/gcc8 ( when not using -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that /lib/libgcc_s.so.1 ends up being used). One result can be _Unwind_RaiseException looping looking at the same frame over and over instead of progressing to the next frame. For example, this happens via cfa_offset 0 being used. devel/powerpc64-gcc -O2 code tends to get that. Notes: For powerpc64, clang++ tends to use another register (%r31) with the old value (of %r1, the stack pointer) instead of involving the DW_CFA_remember_state/DW_CFA_restore_state pair based on just %r1. (clang has other problems relative to sue for buildworld buildkernel.) Code generation styles matter for if the incomplete coverage by /lib/libgcc_s.so will be visible or not. At this stage, WITH_LLVM_LIBUNWIND=3D builds targeting powerpc64 do not even compile/assemble the relevant code, apparently both because of darwin specific assembler code and FreeBSD's build not using the C-preprocessor on the .S file as required. (There could be more to getting it working.) I do not know about other architecture/compiler (or toolchain) combinations that may not yet be able to use WITH_LLVM_LIBUNWIND=3D . But I'd expect a potentially similar status from some. A range of modern /usr/local/lib/gcc*/libgcc_s.so do implement DW_CFA_remember_state/DW_CFA_restore_state operations and they are put to use. So using the likes of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ exception handling (but is problematical for buildworld buildkernel). I made a similar exploration of the issue in around early 2016 and got basically the same results, not that I remembered much. But I now have a small source code example that shows the cfa_offset issue for the likes of devel/powerpc64-gcc output. The standard source for throw_exception in /lib/libgcc_s.so produces the cfa_offset problem when devel/powerpc64-gcc is used to buildworld. This turns all thrown C++ exceptions in to unbounded looping in _Unwind_RaiseException for that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arch@freebsd.org Thu Oct 18 23:43:53 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C806BF78C7C for ; Thu, 18 Oct 2018 23:43:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-4.consmr.mail.bf2.yahoo.com (sonic306-4.consmr.mail.bf2.yahoo.com [74.6.132.43]) (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 642988408D for ; Thu, 18 Oct 2018 23:43:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: q1ZaTX8VM1l3kULXorahx9331cWS_TDGqXFHpdZe4jdHODYK1JGvK3PdZn7BQM7 yzqe323UC4mpXFXu1VsfRMvY5piF50xHWqGuV_4vOlrZYB2wJezl4nhsroZhsxgltp9JQY0wa4FL 1aLHI_Lf8ltoqamWWyvXksw7.dx8NR4jmG1Sb0w5iXNjJNPXbaK2IPSfPDFkpzDpzR_0wv1ZnoYS MXwIrvbGUbYEGMdz.cpO6eTiXLJ_lG3KLOjpFzpGlp0hpz_xgzf7y85fE2iqqvNTPOYLvyblJpgp 599EbgmL5oGvA3vwf7I1vbrLE1ST9yHx1pFp1WSUu5gARHMmKVG7Dm6.3X4vs4FS1J2MgwIOA7Ql G7XuSppDbT2Kv.NZvkO1zHmtAbezz0syLm5nSHq8YswDfQpRfqsL7rCVnE0Z0RNgi8nUn1JW_FIM kMJFvhUAFDnBlTTGnNcn85yrVnom5URogg_5mxsEhNDlXpeE0Jmjk8DsDx8h7dUe5XQE5vdG12uX IZ1rnDYCDWT7ybthDG1abIQNPaAaprSnUDcSwQTHfChNCuD85jocqgrMjqMszJW.QL5ZMmVET3sl pM._9xn0A_w8BZLrUGWqqlXthuO8gWC4wliouHZuzHqC2K7ze1nwdotbyVrboA4yOHsRKjwzjb5s hDvDB3boJV9KIu1MdoXreB2FDVpJqE0n2O.amHXr81t63_d7V5eqFhTxf4DLY6a2wweIH6F0U6mp HU6BCM5oL3c7Y4ywH7UQ9OfPSKK1S_kuujsmhSQEmskSa7HqQ4EhejftIvralY0jMxRy05XeshBY uRIvI566oikq3RNLAH0f5y6.THssVTQFBa3hyvUUj62hPD2ZwqSzkXJUJiA3_aDvgLRWa9q.8nbu 3FywMvqn4SSCgsuEtJE.1EuK4cfNaZAV8YVapjiLquvSOtIZ3VpUvhHGvHaZU.gVm0R64dHaru6o Az6RWfDrOn8f6BWr2JNHac_OqORB6GY0N3QCoAkpu20_6d85QZrAimCuucqhFEnaUeYBJfDtn2tZ 3wQwowzR6be55c340PDPsTYCgAP_j0cWGVEoXkitfEHFDnVWTvWAwf3vR_9n0X9UNsz0vAC0ARlX 3sweLJLo4pDx_qzVqHA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 18 Oct 2018 23:43:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a646330be3e13d20eaceb7b17daac9d4; Thu, 18 Oct 2018 23:43:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) From: Mark Millard In-Reply-To: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Thu, 18 Oct 2018 16:43:40 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 23:43:54 -0000 [I add a note indicating that clang++ does generate examples of DW_CFA_remember_state and DW_CFA_restore_state use for pwoerpc64 that lead to /lib/libgcc_s.so messing up the exception handling.] On 2018-Oct-17, at 1:25 PM, Mark Millard wrote: > [This summarizes other results without the code > and debugger evidence and such from my recent > explorations. It should be much easier to > follow than my exploration reports.] >=20 > Documents like DWARF5.pdf document the "row" vs. Location > information for Call Frame Information as (also used > for .eh_frame like materials for C++ exception handling): > (CFA: Cannonical Frame Address) >=20 > QUOTE ("Structure of Call Frame Information") > LOC CFA R0 R1...RN >=20 > L0 >=20 > L1 >=20 > ... >=20 > LN > END QUOTE >=20 > Note that the CFA is conceptually one of the > registers in each row, even though it is not a > machine register but a way to calculate the > conceptual register's value from machine > registers. >=20 > The information for the machine registers are > typically based on the earlier CFA value (from > the same row!). Absent a correct CFA cell in > a row, most potential use of that row is likely > messed up. >=20 > One way CFA is found is by adding an offset to > the value of a machine register for the range > in question, Ln up to L(n+1) [or based on the > end of the overall range for the last Ln]. I > will use that for illustration because there > are examples of this in my testing. >=20 > /lib/libgcc_s.so.1 does not implement this > fully for some DW_CFA_* operations: >=20 > QUOTE (note the "every register" reference, so including CFA) > DW_CFA_remember_state >=20 > The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. >=20 > DW_CFA_restore_state >=20 > The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. > END QUOTE >=20 > In other words: push and pop a complete row, > not just machine registers information from > the row. >=20 > For example, the the "cfa_offset" for computing the CFA > value from from a register is not saved and restored. > Nor is which register the offset is based on. (This > can vary, though not in my examples.) In general the > CFA cell is not saved and restored, what ever its > contents. >=20 > So any compiler that produces code depending on > DW_CFA_remember_state and DW_CFA_restore_state > for .eh_frame like material ends up with C++ > exception handling messed up when the > DW_CFA_restore_state should change the CFA to a=20 > non-default one (from the prior > DW_CFA_remember_state). >=20 > This prevents reliable use of throwing C++ exceptions > when building via the likes of devel/powerpc64-gcc > or lang/gcc8 ( when not using > -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that > /lib/libgcc_s.so.1 ends up being used). One result > can be _Unwind_RaiseException looping looking at > the same frame over and over instead of progressing > to the next frame. For example, this happens via > cfa_offset 0 being used. devel/powerpc64-gcc -O2 > code tends to get that. >=20 >=20 > Notes: >=20 > For powerpc64, clang++ tends to use another register > (%r31) with the old value (of %r1, the stack pointer) > instead of involving the > DW_CFA_remember_state/DW_CFA_restore_state pair > based on just %r1. (clang has other problems > relative to sue for buildworld buildkernel.) /usr/tests/lib/atf/libatf-c++/detail/exceptions_test has examples were clang++ generated use of DW_CFA_remember_state and DW_CFA_restore_state and /lib/libgcc_s.so 's _Unwind_RaiseException ends up stuck looping. There are other examples as well. The problem is not limited to devel/powerpc64-gcc or other g++ use that uses /lib/libgcc_s.so . > Code generation styles matter for if the incomplete > coverage by /lib/libgcc_s.so will be visible or not. >=20 > At this stage, WITH_LLVM_LIBUNWIND=3D builds > targeting powerpc64 do not even compile/assemble > the relevant code, apparently both because of > darwin specific assembler code and FreeBSD's build > not using the C-preprocessor on the .S file as > required. (There could be more to getting it > working.) >=20 > I do not know about other architecture/compiler > (or toolchain) combinations that may not yet be > able to use WITH_LLVM_LIBUNWIND=3D . But I'd > expect a potentially similar status from some. >=20 > A range of modern /usr/local/lib/gcc*/libgcc_s.so > do implement DW_CFA_remember_state/DW_CFA_restore_state > operations and they are put to use. So using the likes > of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ > exception handling (but is problematical for buildworld > buildkernel). >=20 > I made a similar exploration of the issue in around > early 2016 and got basically the same results, not that > I remembered much. But I now have a small source code > example that shows the cfa_offset issue for the likes > of devel/powerpc64-gcc output. >=20 > The standard source for throw_exception in > /lib/libgcc_s.so produces the cfa_offset problem > when devel/powerpc64-gcc is used to buildworld. > This turns all thrown C++ exceptions in to > unbounded looping in _Unwind_RaiseException for > that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)