On Thu, Sep 12, 2019 at 2:13 PM Michał Górny <mgo...@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 <ken...@gentoo.org> wrote: > > > > > On Wed, 11 Sep 2019 17:28:22 -0700 > > > Alec Warner <anta...@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 > >
