From: Kent Fredric <kentnl@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules
Date: Fri, 13 Sep 2019 21:13:00 +1200 [thread overview]
Message-ID: <20190913211300.1a8c2df7@katipo2.lan> (raw)
In-Reply-To: <fb69edb46ddc128dd5c032e3d3a0869be140e23b.camel@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On Thu, 12 Sep 2019 23:12:52 +0200
Michał Górny <mgorny@gentoo.org> 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 )
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-09-13 9:13 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 17:21 [gentoo-dev] [PATCH 0/3] add eclass to handle go modules William Hubbs
2019-09-11 17:21 ` [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new " William Hubbs
2019-09-11 17:38 ` Michał Górny
2019-09-11 18:22 ` William Hubbs
2019-09-11 18:31 ` Michał Górny
2019-09-11 19:40 ` William Hubbs
2019-09-11 19:47 ` Michał Górny
2019-09-11 23:11 ` William Hubbs
2019-09-12 5:39 ` Michał Górny
2019-09-12 16:39 ` William Hubbs
2019-09-12 17:03 ` Michał Górny
2019-09-12 20:16 ` Kent Fredric
2019-09-12 21:10 ` Michał Górny
2019-09-11 23:31 ` Alec Warner
2019-09-12 0:05 ` William Hubbs
2019-09-12 0:28 ` Alec Warner
2019-09-12 15:36 ` William Hubbs
2019-09-12 20:20 ` Kent Fredric
2019-09-12 20:38 ` Alec Warner
2019-09-12 21:12 ` Michał Górny
2019-09-12 22:01 ` Alec Warner
2019-09-13 9:13 ` Kent Fredric [this message]
2019-09-11 17:21 ` [gentoo-dev] [PATCH 2/3] app-misc/spire: migrate to go-module.eclass William Hubbs
2019-09-11 17:21 ` [gentoo-dev] [PATCH 3/3] dev-vcs/hub: " William Hubbs
2019-09-11 17:39 ` Michael Orlitzky
2019-09-11 17:47 ` William Hubbs
2019-09-11 17:48 ` Michael Orlitzky
2019-09-11 19:15 ` Kent Fredric
2019-09-11 19:26 ` William Hubbs
2019-09-11 23:34 ` Alec Warner
2019-09-11 23:48 ` William Hubbs
2019-09-12 0:05 ` Alec Warner
2019-09-12 15:46 ` William Hubbs
2019-09-12 16:14 ` Michael Orlitzky
2019-09-12 16:42 ` Alec Warner
2019-09-12 16:52 ` Michael Orlitzky
2019-09-12 16:55 ` Mike Gilbert
2019-09-12 17:05 ` Michael Orlitzky
2019-09-12 17:43 ` Mike Gilbert
2019-09-12 21:11 ` Michael Orlitzky
2019-09-12 21:23 ` Mike Gilbert
2019-09-13 0:14 ` Michael Orlitzky
2019-09-13 1:56 ` Alec Warner
2019-09-13 2:16 ` Alec Warner
2019-09-13 3:13 ` Mike Gilbert
2019-09-13 12:11 ` Michael Orlitzky
2019-09-12 17:45 ` Alec Warner
2019-09-12 21:58 ` Michael Orlitzky
2019-09-13 9:19 ` Kent Fredric
2019-09-13 12:29 ` Michael Orlitzky
2019-09-13 20:17 ` Patrick McLean
2019-09-13 23:44 ` Michael Orlitzky
2019-09-14 0:22 ` Patrick McLean
2019-09-14 17:06 ` Alec Warner
2019-09-14 22:37 ` Michael Orlitzky
2019-09-16 7:54 ` Kent Fredric
2019-09-14 6:52 ` Ulrich Mueller
2019-09-13 16:50 ` Michael Orlitzky
2019-09-13 20:52 ` Patrick McLean
2019-09-16 8:11 ` Kent Fredric
2019-09-12 20:10 ` Kent Fredric
2019-09-12 17:31 ` Michał Górny
2019-09-12 16:46 ` Alec Warner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190913211300.1a8c2df7@katipo2.lan \
--to=kentnl@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox