From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 492F4138334 for ; Fri, 13 Sep 2019 09:13:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 96064E0D27; Fri, 13 Sep 2019 09:13:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 454B6E0BC2 for ; Fri, 13 Sep 2019 09:13:11 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id B727E34B102 for ; Fri, 13 Sep 2019 09:13:09 +0000 (UTC) Date: Fri, 13 Sep 2019 21:13:00 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules Message-ID: <20190913211300.1a8c2df7@katipo2.lan> In-Reply-To: References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-2-williamh@gentoo.org> <20190912000525.GB21591@whubbs1.dev.av1.gaikai.org> <20190913082028.7b478cb1@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/liBUC2yPGyN45uLtAOXL6v1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Archives-Salt: 0eb3e2c9-1c1a-4002-b0b5-ac58f07780b5 X-Archives-Hash: 6c6bfc958cfae048de1597a95d30aec9 --Sig_/liBUC2yPGyN45uLtAOXL6v1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 12 Sep 2019 23:12:52 +0200 Micha=C5=82 G=C3=B3rny wrote: > Since when it is a bug that when you strip debug info, you don't have > debug info? I thought that's precisely what stripping debug info means > but maybe in the special Go world it is different, and debug info is > expected to remain after stripping it. I think the distinction may be because typically, people use external tools to consume debug info, thus, people without said tools aren't disadvantaged by stripping. But when the program itself uses its own debug info as part of its behaviour, it seems more reasonable that you might want to keep those. For instance, if you build a rust binary "without debugging" and "with optimization", you still actually get *some* debugging symbols, just not all of them, and you still get useful backtraces that are vaguely related when a panic happens. But if you point strip at it, panic-backtraces become much less useful. And given the nature of Rust and Go, where tripping a panic is pretty much a "file a bug immediately" situation, it seems silly to have programs having the capacity to print their own backtraces, but also being useless for reporting bugs. ( I need to look into if rust does the right thing if you do split-debugs, but I doubt it, I was under the impression bringing the split debug info back into context is gdb magic ) --Sig_/liBUC2yPGyN45uLtAOXL6v1 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAl17XZwACgkQda6SGagV g7UO9g/+JyhHykSRNc9KKbVWdL92yo0IzOyHTr+1uz7Awnh0dx20DQoO+3HQvvcl /5NGaLjPKse1otKuQYtli/Wino9dhlBssscOWEZu8l9fw7hiTBUrcyP/PJzC8hU/ d5f23dUCviBuQUvwozTlyZqrhoXa+zUqU5/x1dyo1AoY5xRbQU//fWZRjt3o8USU OZe2+ZEKaJ5X/Af+bi+EQ9nCDKRuGrSs4XLUUNjNVZ5cCTzT5Csw9qQan8KNv7Iy 58RNjT3k5oSpR6/K2fQSRj0cN8LFjXJ/rh9gW2hCK2zPgFiTkHOQPzaRqpoKsAKJ FkPEcPFoeyptB8mWpH8mIrQgHvTo7p69IsEmfp6C5w9OphlukxroPJkHDXrmpmJz iG/sHNp0rfVxUQ92skGvH4KuYy9+Gvz2qUtDaGtad1pd+PrgNQNZgftPqRZLy5t/ B3rGNgMAIJHZIO6V+ir/+hf8z5U/81Gf/GVv5tHtugZEXGGhLzHn9es3FXyDhXQy zvYBX3xbqU9102pCy8NLWKMl3m1cWdtmSn9we/npXvDxpaINZyL1cMcN1ApDdOZt 1W2LUOvz4t0uwDxyxoj3QfCcfiKC68HdUzXO3Ppzmba/wcRysJUl9J0MnS+rXymS HKjbenk+TCTcOZnBCgYyVA3ID0WuJlNvsIH5oq6YlEjCVRCH4UQ= =9/Nf -----END PGP SIGNATURE----- --Sig_/liBUC2yPGyN45uLtAOXL6v1--