Re: [RFC PATCH] Enabling ld -r ELF .stab/.stabstr optimization

[Ian Lance Taylor <ian at airs dot com>]

Earl Chew <earl_chew@agilent.com> writes:

> My theory is that this information is duplicated across many .o files,
> and for each of these .o files, the .stabs/.stabstr optimisation
> code repeatedly walks the debugging information to match the
> repeated header inclusion sequence.

This seems likely.  However, I recommend that whenever you try to
optimize the linker, you build a profiled version to confirm your
intuition, and to enable you to measure the results of improvements.

> My initial thought was to cache relevant information when the
> BINCL is first skipped, and on subsequent occurrences use this
> information to quickly skip over the BINCL.
> 
> There may be some heuristics that could be applied to make sure
> that it's ok to apply the cached information, but I was concerned
> that there may be pathological cases where one #include may
> result in different debugging information from another.

There are pathological cases, although they are usually the result of
dubious programming practices.  A less pathological case to consider
is large projects in which the same base file name is used multiple
times.

I suppose you could also consider using DWARF debugging information.

I think the best approach to this sort of thing is to teach gdb to
read debugging information out of the .o files.  Then the linker
doesn't ever have to read and write most of the debugging information.
In a large project the savings should be significant.

Ian