> [ On Friday, December 10, 2004 at 10:33:50 (+0100), Igor Sobrado wrote: ]
> > Subject: Re: bin/28590: binaries in NetBSD 2.0 should be stripped
> >
> > As this information
> > was not available in earlier NetBSD releases I supposed that both
> > symbol tables information and debuggin information (source code)
> > was provided in the binaries, as a consequence of a flag not added
> > (-s) to the linker when building the production binaries.  I did
> > not run gdb(1) on any binary to check this issue.
> 
> No problem!

Thanks!  :-)

> > I am not the only NetBSD user that supposed that it was a mistake
> > in the building process, as this change was NOT clearly documented.
> 
> No doubt you are correct.
> 
> It has been a change I've been eagerly anticipating for a long time
> now, so I've forgotten that it may be a small surprise to some folks.

A surprise for a lot of folks, though!

I downloaded one of the NetBSD 2.0 RC5 ISO images that Karsten did
some time ago.  I supposed that binaries in that image were not
stripped because it was an experimental release.  It was a big
surprise having not stripped binaries in the final ISO images too.
Perhaps I should read mailing lists more carefully!  ;-)

On another issue.  The entries in the rescue directory of the live CDs
should be links to the same binary, though.  The ISO images provided
for the ACM Programming contests have different binaries with the
same checksum.  Perhaps symbolic links should be provided using SUSP
records.  I am not sure about how those images are build, but mkisofs(8)
can find hard links by caching inodes.  Perhaps it is a good improvement
to get some free space on the live CDs.  I did not run other live CDs,
only that one.  OTOH, it is a very nice work!  A CD full of useful tools.
I learned a lot from it.  :-)

> Note that the difference between the normal symbol table information and
> the full debugging tables provided when things are compiled with '-g' is
> quite significant (though the objects still don't include the actual
> source code -- just pointers to the files and the line numbers in them).

I was not aware about this difference.  I only used debuggers with my
own binaries (and most of them in IRIX and HP-UX platforms) and
source code was always available in the local disks (and I did not
moved it to other directories).  Thanks a lot for this tip!

> Let me assure you that if the binaries contained full '-g' info then
> you'd probably be well aware of it!  For example a static-linked "sh" on
> the alpha platform has the following different file sizes with and
> without the '-g' information:
> 
> $ ls -l NetBSD-1.6.x-alpha-destdir*/bin/sh
> -r-xr-xr-x  1 woods  wheel   605639 Nov 22 20:19 NetBSD-1.6.x-alpha-destdir-n
> o-g/bin/sh
> -r-xr-xr-x  1 woods  wheel  2171367 Nov 22 20:19 NetBSD-1.6.x-alpha-destdir/b
> in/sh

Same happens here... there is even more additional information in
the binaries that run on SPARC platforms!  Some of those 2 MB files
can be stripped (removing all symbols from the executable) to sizes
smaller than 200 KB!

> However even then the resources needed to load and start running the
> programs are the same:
> 
> $ size NetBSD-1.6.x-alpha-destdir*/bin/sh  
> text    data    bss     dec     hex     filename
> 499946  18072   21604   539622  83be6   NetBSD-1.6.x-alpha-destdir-no-g/bin/s
> h
> 499946  18072   21604   539622  83be6   NetBSD-1.6.x-alpha-destdir/bin/sh
> 
> So in the end if you've got _lots_ of spare disk space then there's no
> real harm (performance-wise) in having all that extra information handy
> -- it certainly does make debugging core files even easier.  :-)

In other words, there is a little overhead when the binary is loaded
in the computer memory but it does not require more resources to run!
I never run size(1) on binaries build with and without '-g'.  I am
surprised to see that all section sizes are the same!

> (it does make installs and upgrades a bit slower though -- and e.g. for
> the alpha a full static-linked release with '-g' info won't fit on a
> single CD-ROM :-)

I really hope that NetBSD will not be so large in the future!  :-)

BTW, I found other changes very useful.  For example, sendmail not
only runs as a non privileged user by default now (I will check
if an unprivileged user can list the mail queue as soon as I arrive
to home), but it also listens on local interfaces only!!!  This
change is really nice not only for sending mail locally (e.g., emails
sent by vi(1)) in a secure way but also for people, as me, that wants
to run fetchmail(1) for retrieving email.  A nice and secure default
configuration for sendmail.

The only feature that is missing is a BSD licensed diff and diff3
utilities.  Those tools are not available yet.  The ones provided in
OpenBSD are nicely documented.  A replacement for bc(1) and dc(1)
would be great too.  I like the ones provided in OpenBSD, but
some non standard features are missing yet.

Have a very nice day,

Igor.