On Thu, Sep 12, 2019 at 2:13 PM Michał Górny <mgorny@gentoo.org> wrote:

> 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
>
>