On Thu, 12 Sep 2019 23:12:52 +0200 Michał Górny <mgo...@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 )
pgpujAS9Gjbpb.pgp
Description: OpenPGP digital signature
