Re: how to get "the big picture" with nm, objdump, size for object size?

[Ilya Murav'jov <muravev at yandex dot ru>]

Ilya Murav'jov ÐÐÑÐÑ:
> Hi all!
> 
>  I am trying to decrease the object size for my C++ code with nm, size
> and objdump. The 'size' command gives me
> $ size my_obj.o
>    text    data     bss     dec     hex filename
>  143576      72     208  143856   231f0 my_obj.o
> just 143kb which is much less than real file size (which is 1,6Mb).
> 
>  So, how can I get what sections occupy so many space? I am sure they
> are debugging symbols and something else; so, how can I sum up numbers
> from output of the tools to get something like 1,6Mb? Googling didn't help.
> 

Thanks for all suggestions, on top of 'readelf -S' I have made a simple
script with output like so:

$ print_object.py my_obj.o
Name                Size      %         Comment

DEBUG               1097535   71.40     .debug_*, .rel.debug_*
OTHER               85914     5.59      all other sections
shstrtab            96797     6.30      names of other sections
strtab              106146    6.90      section with names for .symtab
symtab              57824     3.76      symbol info section
text                93043     6.05      instructions, of a program

Total:              1537259   100.00

The difference 1,6Mb-1,5Mb is not so big now (I think the missed space
is Section Header Table, right?). If someone is interested I post the
script here.

And I have 2 questions too.
1. Static libraries vs shared libraries. As I said before, my code uses
C++ templates heavily, so it is not surprise that many identical symbols
are put in every object file (they are weak, "W", "w", "V", "v"). Then I
use ar & ranlib to get static libraries; then link final executables
from libs. My static libraries is rather big, ~50Mb, so it is slow to
link executables.
 I think that using shared libraries will *greatly* reduce link times,
am I right? The reason is those static libraries hold many those
identical weak symbols, one per object file in a static library.

2. As you can see, debug sections occupy very much space (for
executables they hold even more, ~86%). It is too slow to transfer it
from object files to libraries, then to executables. What about to keep
debug data in a database? For example, assembler (as) generate object
files as usual but without debug symbols which it adds to db. Linker
(ld) then see the object files and knows where debug symbols (by path).
Furthermore, linker can avoid storing debug symbols too, so debugger
(gdb) just uses the database. The info about database is to be learned
from ... hmm ... environment variable, like GNU_DEBUG_SYMS. What do you
think about it?

Regards,
 Ilya