On Thu, 2019-09-12 at 13:38 -0700, Alec Warner wrote:
> On Thu, Sep 12, 2019 at 1:20 PM Kent Fredric <kentnl@gentoo.org> wrote:
>
> > On Wed, 11 Sep 2019 17:28:22 -0700
> > Alec Warner <antarus@gentoo.org> wrote:
> >
> > > I don't care if you strip or not (I'm not even sure portage knows how to
> > do
> > > it for go binaries) but I'm fairly sure the reason isn't because
> > "upstream
> > > does not support stripping go binaries" because they clearly do...unless
> > > upstream is portage here...?
> >
> > I know rust at least has some sort of magic in place where if you do
> > strip a binary, the ability for it to produce useful stack traces when
> > it crashes is reduced.
> > ( In that, it can make use of debugging symbols without the aid of a
> > debugger )
> >
> > I can imagine that could be a reason to not support it.
> >
>
> You definitely should not call 'strip' on a go binary. If you build with
> the aforementioned linker flags you still get proper panic backtraces, but
> also smaller binaries that you cannot load into gdb. Why 'strip' can't do
> this but the go compiler can seems to be a bug ;)
>
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.
So I have not checked (I should ask go-nuts about it) but it's possible that:
strip <some_go_binary> breaks panic() tracebacks # This is generally bad.
go_compiler -w -s <some_binary> removes debug info, produces a smaller binary, but has working panic() tracebacks.
In this case we would:
- Prefer the latter over the former.
- Ideally make it so that strip emulates -w -s, but keeps panic metadata for go programs.
Not sure if upstream has rejected those patches, I can follow up.
-A
--
Best regards,
Michał Górny