stripping gccgo binaries

[Michael Hudson-Doyle]

Hi all,

Following up on my thread on golang-dev about stripping gc-built binaries...

I'd generally been of the impression that you can't strip any
gccgo-built binary, but that seems not to be the case -- on trying
with newish gccgo at least, stripping some simple programs and some
not so simple programs seems to work. Stripping juju results in a
binary that breaks on startup though. So I thought I'd ask here to see
what the expectations are -- are the simpler things working by luck,
or is it a bug that stripping juju causes failures?

Cheers,
mwh

[Ian Lance Taylor]

The simpler examples are more or less working by luck. If you strip a
binary, runtime.Caller and runtime.Callers stop working. Of course
most simple programs never call those functions. But complex ones do.

Ian

[Michael Hudson-Doyle]

OK. So "do not strip gccgo binaries" still seems like good general
advice, but simple things that are known not to call Callers or Caller
might be safe?

Is there any prospect of lifting this, i.e. implementing Caller or
Callers without needing debug data?

Cheers,
mwh

[Ian Lance Taylor]

On Thu, Mar 31, 2016 at 3:39 PM, Michael Hudson-Doyle
<michael...@canonical.com> wrote:
> OK. So "do not strip gccgo binaries" still seems like good general
> advice, but simple things that are known not to call Callers or Caller
> might be safe?

Yes.

> Is there any prospect of lifting this, i.e. implementing Caller or
> Callers without needing debug data?

It is theoretically possible. We could, for example, run a program on
the .o file that copies the debug line info to a separate section that
the strip program does not discard. Of course the resulting binaries
would become much larger. Another approach would be to modify the
strip program to recognize Go binaries and not discard their
debug_line info.

Ian