| 1 |
On Thu, 12 Sep 2019 23:12:52 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Since when it is a bug that when you strip debug info, you don't have |
| 5 |
> debug info? I thought that's precisely what stripping debug info means |
| 6 |
> but maybe in the special Go world it is different, and debug info is |
| 7 |
> expected to remain after stripping it. |
| 8 |
|
| 9 |
I think the distinction may be because typically, people use external |
| 10 |
tools to consume debug info, thus, people without said tools aren't |
| 11 |
disadvantaged by stripping. |
| 12 |
|
| 13 |
But when the program itself uses its own debug info as part of its |
| 14 |
behaviour, it seems more reasonable that you might want to keep those. |
| 15 |
|
| 16 |
For instance, if you build a rust binary "without debugging" and "with |
| 17 |
optimization", you still actually get *some* debugging symbols, just |
| 18 |
not all of them, and you still get useful backtraces that are vaguely |
| 19 |
related when a panic happens. |
| 20 |
|
| 21 |
But if you point strip at it, panic-backtraces become much less useful. |
| 22 |
|
| 23 |
And given the nature of Rust and Go, where tripping a panic is pretty |
| 24 |
much a "file a bug immediately" situation, it seems silly to have |
| 25 |
programs having the capacity to print their own backtraces, but also |
| 26 |
being useless for reporting bugs. |
| 27 |
|
| 28 |
( I need to look into if rust does the right thing if you do |
| 29 |
split-debugs, but I doubt it, I was under the impression bringing the |
| 30 |
split debug info back into context is gdb magic ) |
Archives