Go patch committed: Don't strip Go programs

Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

This patch to the gccgo manual clarifies that you should not strip Go
programs, as requested by PR 63565.  I also added a note about using
cgo to interoperate between Go and C.  Bootstrapped on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2015-01-23  Ian Lance Taylor  <iant@google.com>

PR go/63565
* gccgo.texi (Invoking gccgo): Mention that Go programs should not
be stripped.

* gccgo.texi (C Interoperability): Mention that people should use
cgo.

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

On Fri, Feb 27, 2015 at 7:21 AM,  <laboger@linux.vnet.ibm.com> wrote:
>
> As discussed in this bugzilla, the debug info from libgo should not be
> stripped or some things won't work as documented, like runtime.Callers. Is
> that information documented anywhere so that anyone who builds gccgo and
> libgo and provides it to others is aware of this?

I'm not aware of any documentation specifically saying that libgo
should not be stripped.  Do you have any suggestions as to where that
should go?

Ian

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Lynn A. Boger]

At a minimum I think it should be mentioned in libgo/README.

I'll have to ask around to find out where would be best so that anyone 
who builds libgo for distribution knows that the debug info should not 
be stripped.

I'm not sure about other places
On 02/27/2015 09:59 AM, Ian Lance Taylor wrote:
> On Fri, Feb 27, 2015 at 7:21 AM,  <laboger@linux.vnet.ibm.com> wrote:
>> As discussed in this bugzilla, the debug info from libgo should not be
>> stripped or some things won't work as documented, like runtime.Callers. Is
>> that information documented anywhere so that anyone who builds gccgo and
>> libgo and provides it to others is aware of this?
> I'm not aware of any documentation specifically saying that libgo
> should not be stripped.  Do you have any suggestions as to where that
> should go?
>
> Ian
>
>
>

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Matthias Klose]

On 02/27/2015 04:59 PM, Ian Lance Taylor wrote:
> On Fri, Feb 27, 2015 at 7:21 AM,  <laboger@linux.vnet.ibm.com> wrote:
>>
>> As discussed in this bugzilla, the debug info from libgo should not be
>> stripped or some things won't work as documented, like runtime.Callers. Is
>> that information documented anywhere so that anyone who builds gccgo and
>> libgo and provides it to others is aware of this?
> 
> I'm not aware of any documentation specifically saying that libgo
> should not be stripped.  Do you have any suggestions as to where that
> should go?

is there anything which could be stripped without scarifying functionality?
Linux distributions usually strip things by default, so a hint what exactly is
needed to keep the functionality would be appreciated.

thanks, Matthias

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

On Fri, Feb 27, 2015 at 12:07 PM, Matthias Klose <doko@ubuntu.com> wrote:
>
> is there anything which could be stripped without scarifying functionality?
> Linux distributions usually strip things by default, so a hint what exactly is
> needed to keep the functionality would be appreciated.

What is needed is file/line information.  However, I don't know of an
option to strip that discards most debug info but keeps file/line
info.  The gold linker can do it (--strip-debug-non-line) but that
obviously would have to be used when building the library; it doesn't
help at install time.

Ian

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Lynn A. Boger]

On 02/27/2015 02:46 PM, Ian Lance Taylor wrote:
> On Fri, Feb 27, 2015 at 12:07 PM, Matthias Klose <doko@ubuntu.com> wrote:
>> is there anything which could be stripped without scarifying functionality?
>> Linux distributions usually strip things by default, so a hint what exactly is
>> needed to keep the functionality would be appreciated.

I'm not familiar with what sections are being stripped when you say 
"Linux distributions usually strip things by default".  Do you mean only 
the debug sections are usually stripped?
> What is needed is file/line information.  However, I don't know of an
> option to strip that discards most debug info but keeps file/line
> info.  The gold linker can do it (--strip-debug-non-line) but that
> obviously would have to be used when building the library; it doesn't
> help at install time.

I played around with the strip command and from what I can tell it 
doesn't have the right set of options to allow you to remove only debug 
sections and leave other sections intact.  However it looks like you can 
use objcopy to remove specific sections.  The minimum sections I was 
able to remove and get it to work were these.  I first tried with just 
debug_line, and that didn't produce the line numbers; if I added 
debug_info then various errors occurred until I also included 
debug_abbrev, debug_ranges, debug_str.

objcopy -R .debug_aranges -R .debug_frame -R .debug_loc libgo.so.7.0.0

- Lynn
> Ian
>
>
>

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

On Mon, Mar 2, 2015 at 11:50 AM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
>
> objcopy -R .debug_aranges -R .debug_frame -R .debug_loc libgo.so.7.0.0

What percentage of the total size of .debug sections got removed by
this process?

A problem with that approach is that .debug_info and .debug_abbrevs
sections are large but are almost entirely unnecessary to just get
file/line information.  Unfortunately almost unnecessary is not the
same as completely unnecessary; they can be greatly reduced, but not
completely eliminated.

Ian

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Lynn A. Boger]

I removed the 3 debug sections from libgo that were listed on the 
objcopy command.

I left in:  debug_info, debug_line, debug_abbrev, debug_ranges, and 
debug_str in their original form.

On 03/02/2015 01:58 PM, Ian Lance Taylor wrote:
> On Mon, Mar 2, 2015 at 11:50 AM, Lynn A. Boger
> <laboger@linux.vnet.ibm.com> wrote:
>> objcopy -R .debug_aranges -R .debug_frame -R .debug_loc libgo.so.7.0.0
> What percentage of the total size of .debug sections got removed by
> this process?
>
> A problem with that approach is that .debug_info and .debug_abbrevs
> sections are large but are almost entirely unnecessary to just get
> file/line information.  Unfortunately almost unnecessary is not the
> same as completely unnecessary; they can be greatly reduced, but not
> completely eliminated.
>
> Ian
>
>
>

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

On Mon, Mar 2, 2015 at 12:05 PM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
> I removed the 3 debug sections from libgo that were listed on the objcopy
> command.
>
> I left in:  debug_info, debug_line, debug_abbrev, debug_ranges, and
> debug_str in their original form.

Understood.  I mean: if you add up the total sizes of the original
debug info sections, and the total sizes of the remaining debug info
sections, what percentage of the total debug info did you remove?

After all, the only point of removing debug info is to decrease the
size of the files.

Ian


> On 03/02/2015 01:58 PM, Ian Lance Taylor wrote:
>>
>> On Mon, Mar 2, 2015 at 11:50 AM, Lynn A. Boger
>> <laboger@linux.vnet.ibm.com> wrote:
>>>
>>> objcopy -R .debug_aranges -R .debug_frame -R .debug_loc libgo.so.7.0.0
>>
>> What percentage of the total size of .debug sections got removed by
>> this process?
>>
>> A problem with that approach is that .debug_info and .debug_abbrevs
>> sections are large but are almost entirely unnecessary to just get
>> file/line information.  Unfortunately almost unnecessary is not the
>> same as completely unnecessary; they can be greatly reduced, but not
>> completely eliminated.
>>
>> Ian
>>
>>
>>
>

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Lynn A. Boger]

libgo sizes

32665042:  original size

27607770:  after removing the debug sections using the objcopy command 
from below

22474602:  after removing all debug sections using objcopy

On 03/02/2015 02:08 PM, Ian Lance Taylor wrote:
> On Mon, Mar 2, 2015 at 12:05 PM, Lynn A. Boger
> <laboger@linux.vnet.ibm.com> wrote:
>> I removed the 3 debug sections from libgo that were listed on the objcopy
>> command.
>>
>> I left in:  debug_info, debug_line, debug_abbrev, debug_ranges, and
>> debug_str in their original form.
> Understood.  I mean: if you add up the total sizes of the original
> debug info sections, and the total sizes of the remaining debug info
> sections, what percentage of the total debug info did you remove?
>
> After all, the only point of removing debug info is to decrease the
> size of the files.
>
> Ian
>
>
>> On 03/02/2015 01:58 PM, Ian Lance Taylor wrote:
>>> On Mon, Mar 2, 2015 at 11:50 AM, Lynn A. Boger
>>> <laboger@linux.vnet.ibm.com> wrote:
>>>> objcopy -R .debug_aranges -R .debug_frame -R .debug_loc libgo.so.7.0.0
>>> What percentage of the total size of .debug sections got removed by
>>> this process?
>>>
>>> A problem with that approach is that .debug_info and .debug_abbrevs
>>> sections are large but are almost entirely unnecessary to just get
>>> file/line information.  Unfortunately almost unnecessary is not the
>>> same as completely unnecessary; they can be greatly reduced, but not
>>> completely eliminated.
>>>
>>> Ian
>>>
>>>
>>>

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

On Fri, Feb 27, 2015 at 8:37 AM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
> At a minimum I think it should be mentioned in libgo/README.

(Where "it" means that libgo should not be stripped.)

I've committed this minor update to libgo/README.

Ian

[-- Attachment #2: foo.txt --]
[-- Type: text/plain, Size: 1284 bytes --]

diff -r b0d3b9400c63 libgo/README
--- a/libgo/README	Thu Mar 12 15:47:46 2015 -0700
+++ b/libgo/README	Fri Mar 13 11:51:31 2015 -0700
@@ -3,25 +3,24 @@
 This is the runtime support library for the Go programming language.
 This library is intended for use with the Go frontend.
 
-The library has only been tested on GNU/Linux using glibc.  It should
-not be difficult to port to other operating systems.
+This library should not be stripped when it is installed.  Go code
+relies on being able to look up file/line information, which comes
+from the debugging info using the libbacktrace library.
 
-The library has only been tested on x86/x86_64 systems.  It should not
-be difficult to port to other architectures.
+The library has only been tested on GNU/Linux using glibc, and on
+Solaris.  It should not be difficult to port to other operating
+systems.
 
 Directories:
 
 go
-  A copy of the Go library from http://golang.org/, with a few
-  changes for gccgo.  Notably, the reflection interface is different.
+  A copy of the Go library from http://golang.org/, with several
+  changes for gccgo.
 
 runtime
   Runtime functions, written in C, which are called directly by the
   compiler or by the library.
 
-syscalls
-  System call support.
-
 Contributing
 ============