From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4D198138334 for ; Thu, 12 Sep 2019 22:01:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC71BE0CCA; Thu, 12 Sep 2019 22:01:30 +0000 (UTC) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6A74BE0CB4 for ; Thu, 12 Sep 2019 22:01:30 +0000 (UTC) Received: by mail-io1-xd44.google.com with SMTP id k13so43348676ioj.1 for ; Thu, 12 Sep 2019 15:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=j9fEs227CveP+k1kFa9NVASwku3IRaIj0+vXIhvktoE=; b=oH8Q2qExBQItFJDM1M+sR72K23QOoGfCIDOhJXhvY7UwP9sLgRKxAC2lVNAbBFQw0A 6Q3hAh53pIGlvoyevYke5VcrPw/fp1788yqGVWYFfYjV3/A2tRWq3FOP8xabDZvc4wIP jSOMJ7QwspbBlaLWK9zLYoCevhUS0EeJpW0vrjWCOJgtajpKv9knv9kv4NcnP1UUXno4 x5H9WtTG0HtAuY725pXyxmbHgxBRVrYpQ7eMf7dpPIGSomWczbxymZQxN68buEWtfavH hz8bnjFWu/M6XW06JuIWoOf+AeE7ZIF7Gx/5cT1c+7yu9uPYjzgDt+f74/BxCqy4xTSX SGZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=j9fEs227CveP+k1kFa9NVASwku3IRaIj0+vXIhvktoE=; b=WOGSohKYbnbcYVw+Iw5HpYcVmu/L8UZ5hbdmRwDJF5cgsEeR93grfeAmYFhB1p3BYw IkSFjA59cB41Duz2xQapF1TAQ50yZv6kTW8IjOX3S5BpxoSy+S6HMSPXmEHZfEixKNTI QY0GBGt7f6sfc2a+gkMmYTac7A9XeLkFFT2BAf51tVPYiYsWWHZFeHZU89bZA3BPzpps nCoA3MFobCRSAiHsxLs7EemP/48b4cG+dESSDPoGXS4yJD8+zH7MkjiN8YvpAzik20ug zQAwiVa5P5VAauAi/wJeX9bKkSzszWL+qp++WzzMCJn7ic+bMe1PJUcXWDp/aQ/1momB JAZQ== X-Gm-Message-State: APjAAAVcpWdyAevh3u+Xx3i404Ju+4lD3bS37Hmj3Xemo6ZKT89Oigi/ m0BgXCGcvXcrsyDd/VSz/0LRUCqBqKGFta8wlbyRBZtu X-Google-Smtp-Source: APXvYqxazaP2cJmkOxt35SlFLP0tJOsYvZ0Z4QQ6WO3WUwO1DyazWqxV8NnjHVyJT7H1y11WNK7LZhCkTQbgkOknBbc= X-Received: by 2002:a5e:8402:: with SMTP id h2mr7816935ioj.38.1568325689128; Thu, 12 Sep 2019 15:01:29 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-2-williamh@gentoo.org> <20190912000525.GB21591@whubbs1.dev.av1.gaikai.org> <20190913082028.7b478cb1@katipo2.lan> In-Reply-To: From: Alec Warner Date: Thu, 12 Sep 2019 15:01:17 -0700 Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules To: Gentoo Dev Content-Type: multipart/alternative; boundary="00000000000097cc1405926247e3" X-Archives-Salt: a6719590-6d91-4c06-a7e7-7e1aadc8b886 X-Archives-Hash: 70cbff79c165a0ac9cb34e1e15a67dd4 --00000000000097cc1405926247e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2019 at 2:13 PM Micha=C5=82 G=C3=B3rny = wrote: > On Thu, 2019-09-12 at 13:38 -0700, Alec Warner wrote: > > On Thu, Sep 12, 2019 at 1:20 PM Kent Fredric wrote: > > > > > On Wed, 11 Sep 2019 17:28:22 -0700 > > > Alec Warner 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 whe= n > > > 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 wit= h > > 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 breaks panic() tracebacks # This is generally bad. go_compiler -w -s 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=C5=82 G=C3=B3rny > > --00000000000097cc1405926247e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 12, 2019 at 2:13 PM Micha= =C5=82 G=C3=B3rny <mgorny@gentoo.or= g> 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&#= 39;t because
> > "upstream
> > > does not support stripping go binaries" because they cl= early 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 o= f 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= 9; 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?=C2=A0 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_b= inary> removes debug info, produces a smaller binary, but has working pa= nic() tracebacks.

In this case we would:
=C2=A0- Prefer the latter over the former.
=C2=A0- Ideally make = it so that strip emulates -w -s, but keeps panic metadata for go programs.<= /div>

Not sure if upstream has rejected those patches, I= can follow up.

-A

=C2=A0=

--
Best regards,
Micha=C5=82 G=C3=B3rny

--00000000000097cc1405926247e3--