large binary, why not strip ?

Bruce Cran bruce at
Thu Nov 27 01:02:24 PST 2008

On Thu, 27 Nov 2008 07:32:23 +0000
Matthew Seaman <m.seaman at> wrote:

> Paul B. Mahol wrote:
> > On 11/26/08, Matthew Seaman <m.seaman at> wrote:
> >> Matthew Seaman wrote:
> >>> Kris Kennaway wrote:
> >>>
> >>>> Bonus points if you come up with a patch to do this: in most
> >>>> cases it will be a simple matter of changing the port's
> >>>> do-install: target to use INSTALL_* macros instead of cp/bsdtar
> >>>> etc.  This would be a good project to get some familiarity with
> >>>> the ports tree.
> >>> Would it be worthwhile to add a test and warning that all
> >>> installed binaries
> >>> have not been stripped to the 'security-check' target in
> >>> That's
> >>> not really what that target was intended for (feeping creaturism
> >>> alert!) but
> >>> it's the obvious place to put such a test.
> >>>
> >>> Probably cleaner to create a whole new target, but that's going to
> >>> duplicate
> >>> some code.
> >>>
> >>> Hmmmm... I shall work up some patches, probably over the weekend,
> >>> so there's
> >>> something substantive to talk about.
> >> Done: ports/129210
> >>
> >> For the record, I also discovered that, contrary to what I said
> >> earlier, there is  apparently one class of binary object that will
> >> not work correctly if stripped: kernel loadable modules.
> > 
> > Kernel loadable modules are already stripped (--strip-debug).
> > 
> KLDs aren't stripped in a way that file(1) recognises:
> happy-idiot-talk:/boot/kernel:% file if_em.ko 
> if_em.ko: ELF 32-bit LSB shared object, Intel 80386, version 1
> (FreeBSD), dynamically linked, not stripped
> Unfortunately file(1) seems to be about the only tool available to
> test a priori whether a binary object is stripped or not.  It's
> possible that objdump(1) or readelf(1) could do a similar thing, but
> I can't work it out from those man pages.

It seems nm also tells you fairly simply whether a file contains
symbols or not: 

> nm /bin/ls
nm: /bin/ls: no symbols
> nm /usr/local/bin/a2p
00000000004030d0 T Myfatal
0000000000510308 D No
000000000051a200 B Str
0000000000510300 D Yes
0000000000519e00 A _DYNAMIC

KLD .ko files are built with full debug data but the source
information (filenames, line numbers etc.) is stripped out into
separate .ko.symbols files, in a similar way that Windows uses .PDB
files; it lets you store the debug information separately and only
match them up if something goes wrong.

To see if a binary contains source data, you can run 'readelf
-w'; no output seems to mean it couldn't find any data.

Bruce Cran

More information about the freebsd-questions mailing list