This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
excessive stab information
- From: "Andy Chittenden" <AChittenden at bluearc dot com>
- To: <binutils at sourceware dot org>
- Cc: "Martin Dorey" <mdorey at bluearc dot com>
- Date: Mon, 18 Apr 2005 13:43:25 +0100
- Subject: excessive stab information
Some of our executables are quite huge compared with the raw binary
file. For example, one of our elf files is 118298855 bytes whereas the
resulting code size is 6037476 bytes. Another is 772819419 (bin size =
29224584). I think the main reason that the elf files are so big is what
looks like "duplicate" stab information: for example, I think this is
duplicated:
1145 LSYM 0 50 00000000 40601 uint8_t:t(71,1)=(0,11)
1614 LSYM 0 154 00000000 261326 uint8_t:t(165,4)=(0,11)
3435 LSYM 0 50 00000000 567274 uint8_t:t(37,5)=(0,11)
And then there are many referrers to these "different" types which
multiply up the problem.
Obviously, the above is just a small example in the maze of types that
are used.
One thing we've already done is get all compilation units to #include a
file which uses all the plain old data types (or PODs): not only did
this reduce the size of the elf file but it also reduced the time to
link as, I presume, there weren't so many stabs to process - by doing
this, we effectively "standardised" the type ids of the basic types
(int, short etc).
So, is it possible to "optimise" away these duplicate stabs? And, if so,
where would I start looking in the binutils source?
--
Andy, BlueArc Engineering