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]

Re: excessive stab information


"Andy Chittenden" <AChittenden@bluearc.com> writes:

> 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?

I note that you neglected to say which platform you are on and which
version of the binutils you are using.  For cases involving debugging
information, the compiler also matters, and you neglected to say which
compiler you are using.

The stabs code in the linker will already remove duplicate header
files across compilation units.  This is done by looking for N_BINCL
stabs in _bfd_link_section_stabs.  So the first step you should take
is to make sure that uint8_t is only defined once in a single header
file.  If it is, you should get N_BINCL stabs for that header file,
and the linker should eliminate the duplicates.

If you already define uint8_t in a single header file, then this
requires further investigation to find out why the duplicate header
file elimination is not working.

In general you can't trivially optimize away duplicate stabs, without
sacrificing the ability to use gdb.

There has been some work done on not linking debug information from
the object files into the executable, and having gdb fetch it from the
object files, but I'm not sure what the status of that is.  I didn't
see anything in the linker docs about it.

Finally I'll note that most people use DWARF debugging these days, not
stabs.

Ian


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