ld 2.13.2.1 taking ~37 minutes to link file

[Daniel Jacobowitz]

Cleaning up old email...

Thanks for the patch.  Since echristo approved it back in February, I'm
checking this in for HEAD and 2.14.

On Fri, Feb 21, 2003 at 03:07:29PM -0500, Ken Faiczak wrote:
> seems the walk through the section
> should be not be /PDR_SIZE otherwise the writes to tdata are wrong and the 
> i* PDR_SIZE would overflow...
> 
> *** elf32-mips.c        Fri Feb 21 14:05:24 2003
> --- elf32-mips.c  (binutils 2.13.2.1)
> *************** elf32_mips_discard_info (abfd, cookie, i
> *** 1699,1707 ****
> 
>     cookie->rel = cookie->rels;
>     cookie->relend = cookie->rels + o->reloc_count;
> 
> !   for (i = 0, skip = 0; i < (o->_raw_size/PDR_SIZE); i ++)
>       {
>         if (_bfd_elf32_reloc_symbol_deleted_p (i * PDR_SIZE, cookie))
>         {
>           tdata[i] = 1;
> --- 1699,1707 ----
> 
>     cookie->rel = cookie->rels;
>     cookie->relend = cookie->rels + o->reloc_count;
> 
> !   for (i = 0, skip = 0; i < o->_raw_size; i ++)
>       {
>         if (_bfd_elf32_reloc_symbol_deleted_p (i * PDR_SIZE, cookie))
>         {
>           tdata[i] = 1;
> 
> 
> behaviour has moved to elfxx_mips.c but is still wrong
> at the current 1.43 version.
> 
> ken
> 
> 
> 
> -----Original Message-----
> From: Ken Faiczak 
> Sent: Friday, February 21, 2003 1:55 PM
> To: 'binutils@sources.redhat.com'
> Subject: ld 2.13.2.1 taking ~37 minutes to link file
> 
> 
> For our embedded system (mips-wrs-vxworks)
> 
> the final image is linked once -r
> it then munches the tmp.o that is produced to get
> symbols and ctor/dtor/eh_frame stuff
> and then performs the final link and locate it
> 
> Upgrading from 2.11.2 to 2.13.2.1 takes the final link from ~30s to
> 37 minutes.
> 
> tracking it done somewhat
> in elf32_mips_discard_info()
> it spends all this time go through the .pdr section
> calling elf_reloc_symbol_deleted_p()
> 
> the raw size is 798912 
> 
> if I remove the .pdr section which our embedded system does not
> use anyway the link goes back to ~30s.
> 
> It seems this is needed for gdb to be able to do stack tracing etc..
> so it would be nice to have but @ 30+minutes 
> 
> Any thoughts as to why this is so slow.
> 
> System is
> binutils-2.13.2.1
> cygwin 1.3.19
> Win 2K 
> 
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer