Re: parallelized 'ld'?

Re: parallelized 'ld'?

[Andrew Cagney]

[switching mailing lists from binutils@ to gdb@]

> * "gdb used to take inordinate amount of time to load on our platform. The
>    fix  was trivial, which likely means that few people ever use GDB on
>    such large executables."

I believe one identified problem is how the symbol table uses hash 
tables.  The symbol tables are being given a careful upgrade.  Was this 
what you noticed?

As for using GDB on large programs, mozilla is (or was) the reference - 
its startup has gone from impossible to tolerable.  I believe users now 
also have their sights on eclipse (compiled with gcj).  So increasing 
demand is definitly there.

Andrew

Re: parallelized 'ld'?

[Alexander Smundak]

> [switching mailing lists from binutils@ to gdb@]
>
> > * "gdb used to take inordinate amount of time to load on our platform.
The
> >    fix  was trivial, which likely means that few people ever use GDB on
> >    such large executables."
>
> I believe one identified problem is how the symbol table uses hash
> tables.  The symbol tables are being given a careful upgrade.  Was this
> what you noticed?
No, it is handling BINCL records in STABS. I have replaced the linear search
in dbxread.c, function find_corresponding_bincl_psymtab() with hash table,
and this shaved 3 minutes off the GDB initialization time in our case
(on 333MHz Sparc Ultra).
Please note that our compiler is gcc 2.95, and that this is for STABS
debugging
format. I can send the diffs to the interested parties; they are for 5.0
GDB, though.

Alexander Smundak

Re: parallelized 'ld'?

[Andrew Cagney]

> [switching mailing lists from binutils@ to gdb@]
>>
> 
>> > * "gdb used to take inordinate amount of time to load on our platform.
> 
> The
> 
>> >    fix  was trivial, which likely means that few people ever use GDB on
>> >    such large executables."
> 
>>
>> I believe one identified problem is how the symbol table uses hash
>> tables.  The symbol tables are being given a careful upgrade.  Was this
>> what you noticed?
> 
> No, it is handling BINCL records in STABS. I have replaced the linear search
> in dbxread.c, function find_corresponding_bincl_psymtab() with hash table,
> and this shaved 3 minutes off the GDB initialization time in our case
> (on 333MHz Sparc Ultra).
> Please note that our compiler is gcc 2.95, and that this is for STABS
> debugging
> format. I can send the diffs to the interested parties; they are for 5.0
> GDB, though.

Ah.  Unless you/cisco have an assignment, a bug report pointing at the 
offending code would be better.

Andrew

Re: parallelized 'ld'?

[Alexander Smundak]

Andrew,

> >> I believe one identified problem is how the symbol table uses hash
> >> tables.  The symbol tables are being given a careful upgrade.  Was this
> >> what you noticed?
> >
> > No, it is handling BINCL records in STABS. I have replaced the linear
search
> > in dbxread.c, function find_corresponding_bincl_psymtab() with hash
table,
> > and this shaved 3 minutes off the GDB initialization time in our case
> > (on 333MHz Sparc Ultra).
> > Please note that our compiler is gcc 2.95, and that this is for STABS
> > debugging
> > format. I can send the diffs to the interested parties; they are for 5.0
> > GDB, though.
>
> Ah.  Unless you/cisco have an assignment, a bug report pointing at the
> offending code would be better.
It turns out there is already an open PR#975:

Reporter's email:klee@apple.com
Number:975
Category:symtab
Synopsis:[RFA] Use hash to speed up BINCL/INCL processing.
Severity:serious
Priority:medium
State:open
Arrival-Date:Thu Jan 30 04:48:00 UTC 2003
Last-Modified:Sun Feb 16 04:18:00 UTC 2003

Alexander Smundak