> > >>strip --strip-unneeded -R.note -R.comment
> >
> > "strip -R" is equivalent to "strip --remove-section", so some extra
> > information is removed from the binary. I have to admit that I don't
> > really know what information these sections contain.
>
> Me neither, but there are visible results:
>
> wolfstar@ulrik:~ > ls -la libc.so.6*
> -rwxr-xr-x 1 wolfstar users 1382179 May 11 21:25 libc.so.6
> -rwxr-xr-x 1 wolfstar users 1167916 May 11 21:27 libc.so.6-plain
> -rwxr-xr-x 1 wolfstar users 1108748 May 11 21:27 libc.so.6-extra
>
> That's the glibc that comes with SuSE 7.1 - I think glibc 2.2, but I'm not
> sure off the top of my head. (Probably is, 2.1 was 4 megs unstripped.)
> libc.so.6-plain was libc.so.6 just stripped as normal, while -extra was
> done with the funky stuff above. 60k is appreciable. Compressed:
>
> -rwxr-xr-x 1 wolfstar users 523935 May 11 21:25 libc.so.6.gz
> -rwxr-xr-x 1 wolfstar users 451864 May 11 21:27 libc.so.6-plain.gz
> -rwxr-xr-x 1 wolfstar users 451418 May 11 21:27 libc.so.6-extra.gz
>
> 450 bytes ain't much, but it's SOMETHING. (All compressed with gzip -9.)
>
> Worth investigating IMO.
I don't know about the glibc libraries, but I'm pretty familiar with code
sections (thanks to my background with embedded systems, where you have to
deal with a lot of detail handled automatically in more complex
environments). When writing code, you can tell the compiler/linker which
"section" various pieces of code/data belong in, so the linker knows where
to put everything. There are typically a number of pre-defined sections for
things like executable code, constants, initialized variables, uninitialized
variables, etc... On an embedded system, you tell the linker where to put
each section, so your constants and code might go into ROM, while the
variables get put into SRAM or DRAM...section information is stored in the
executable files and the dynamic loader relocates sections 'on the fly' for
complex systems like linux, as well as things like loading any other
required libraries, initializing RAM, and other low-level details most folks
never worry about.
There are several code sections defined by convention on virtually all
systems (even things like lowly single-chip micros deal with code sections
so you put data in the right place...it's kind of imporant that your
bootstrap code actually goes into [EP]ROM, and variables wind up in RAM
somewhere), but you can also define your own code sections at will. Unless
the linker (or some other tool) knows what to do with the new code sections,
however, they won't be very useful.
Without going through the glibc source code, and the dynamic
loader/relocater (the tool that reads an elf file from your disk, puts it
somewhere in memory, and gets everything ready to run), I can't say for
sure, but if the names are at all descriptive, the .note and .comment
sections don't exactly sound like critical information required to run the
libraries. They are likely additional information that might be useful if
you're running some sort of advanced debugger, but sound quite unnecessary
for our typical floppy-disk based systems.
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
