This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]