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: [RFC PATCH] Enabling ld -r ELF .stab/.stabstr optimization


Ian Lance Taylor wrote:
> I still don't think -r should imply --traditional-format.

I have another question.

I've noticed that the performance of the .stabs/.stabstr optimisation
code is pretty bad for our builds. Non-optimised links (discarding
stabs) take about 40 secs. Optimised links which have /DISCARD/
on the debugging sections (thus performing the optimisation, but
not writing out the results) take about 2 min 40 secs. Optimised
links _without_ /DISCARD/ take about 2 min 50 secs.

The bulk of our code is C++ which is standardised to accommodate
precompiled headers. Thus there are many .o files which have a
more or less standard #include preamble sucking in many standard
headers.

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.

I've been thinking about ways in which ld might be able to sense
and skip over the previously seen .stabs/.stabstr sequence (due
to #include) very quickly, without having to parse each octet.

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.

Do you have any ideas?

Earl


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