RE: infinite loop in ld
Thats a known problem with binutils on alpha. The ld process finishes always
(so no infinite loop) but it takes 100x so long than normal for C++
programs. The problem is described in the bug report at debain and at
sourceware.org:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334766
http://sourceware.org/bugzilla/show_bug.cgi?id=1543
As a fine temporary workaround is to use --no-relax when linking (a patch
could be to make --no-relax a default option on alpha!):
use ld --no-relax, or pass compiler with -Wl,--no-relax or patch --no-relax
to
default / --relax as optional and everything turn to be fine after :-)
firefox links in /layout now in 11 minutes instead of 4:30 hour, and anyway
i
think we could live without relax.
I bootstrapped to alphacore [fedora-devel] this way with latest CVS pool of
glibc/gcc-4.1.2/binutils and everything seems fine.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Luc Papeleux [mailto:L.Papeleux@ulg.ac.be]
> Sent: Tuesday, April 17, 2007 11:58 AM
> To: debian-alpha@lists.debian.org
> Subject: infinite loop in ld
>
> Hi,
>
> Since I updated a compaq XP1000 (alpha EV6) from sarge to etch my large
> c++ program
> (650 objects + dynamicaly linked libraries) does not link anymore :
>
> building objects last 3 to 4 hours (on each distribution)
> linking dynamic libraries (.so) is ok on each distribution
> ld that lasted less than 20seconds on Sarge (GNU ld version 2.15)
> run for 2 hours on Etch with no results (GNU ld version 2.17 Debian
> GNU/Linux)
>
> I attached ld process inside ddd and stopped it at several time and it
> seemed to spend a lot of time
> inside : bfd_elf64_archive_slurp_armap () (se output of gdb below - is
> this significant)
>
> small c++ programs (1-2 files) compiles and link without problems (i am
> unable to reproduce the problem
> with small examples)
>
> Does someone have an idea how to solve the problem (or which information
> could help to reproduce
> the problem)
>
>
> Thanks in advance
>
> Luc
>
> ====================================================================
>
> Versions of installed packages (everythin is (normaly) up to date to
> Etch)
> gcc : gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> ld : GNU ld version 2.17 Debian GNU/Linux
> kernel : 2.6.18-4-alpha-generic
>
> Sarge : compile & link OK
> gcc : 3.3.6 (home compilation)
> ld : GNU ld version 2.15
> kernel : 2.4.27-2-generic
>
> Sarge altenative configuration : compile & link OK
> gcc : 4.1.1 (home compilation)
> ld : GNU ld version 2.15
> kernel : 2.6.8-2-generic
>
>
>
>
> ==========================================================================
> =
> Copyright C 2001-2004 Free Software Foundation, Inc.
> (gdb) file /usr/bin/ld
> (no debugging symbols found)
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) attach 8211
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> 0x00000200000709c8 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> (gdb) where
> #0 0x00000200000709c8 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd-
> 2.17.so
> #2 0x000002000005e4c8 in bfd_link_hash_traverse () from
> /usr/lib/libbfd-2.17.so
> #3 0x0000020000072abc in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #4 0x0000020000075294 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #5 0x0000000120013fd4 in ?? ()
> #6 0x0000000120013ae0 in ?? ()
> #7 0x0000000120013cc4 in ?? ()
> #8 0x00000001200144b8 in ?? ()
> #9 0x0000000120014714 in ?? ()
> #10 0x0000000120017b18 in ?? ()
> #11 0x000000012001cb20 in ?? ()
> #12 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1
> #13 0x0000000120003f78 in ?? ()
> (gdb)
>
> Program received signal SIGINT, Interrupt.
> 0x000002000008a6c4 in _bfd_elf_dynamic_symbol_p () from
> /usr/lib/libbfd-2.17.so
> (gdb) where
> #0 0x000002000008a6c4 in _bfd_elf_dynamic_symbol_p () from
> /usr/lib/libbfd-2.17.so
> #1 0x0000020000078490 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #2 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd-
> 2.17.so
> #3 0x000002000005e4c8 in bfd_link_hash_traverse () from
> /usr/lib/libbfd-2.17.so
> #4 0x00000200000729f8 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #5 0x00000200000759f4 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #6 0x0000000120013fd4 in ?? ()
> #7 0x0000000120013ae0 in ?? ()
> #8 0x0000000120013cc4 in ?? ()
> #9 0x00000001200144b8 in ?? ()
> #10 0x0000000120014714 in ?? ()
> #11 0x0000000120017b18 in ?? ()
> #12 0x000000012001cb20 in ?? ()
> #13 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1
> #14 0x0000000120003f78 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> Program received signal SIGINT, Interrupt.
> 0x00000200000784c4 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> (gdb) where
> #0 0x00000200000784c4 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd-
> 2.17.so
> #2 0x000002000005e4c8 in bfd_link_hash_traverse () from
> /usr/lib/libbfd-2.17.so
> #3 0x00000200000729f8 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #4 0x00000200000759f4 in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #5 0x0000000120013fd4 in ?? ()
> #6 0x0000000120013ae0 in ?? ()
> #7 0x0000000120013cc4 in ?? ()
> #8 0x00000001200144b8 in ?? ()
> #9 0x0000000120014714 in ?? ()
> #10 0x0000000120017b18 in ?? ()
> #11 0x000000012001cb20 in ?? ()
> #12 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1
> #13 0x0000000120003f78 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
> (gdb) c
> ^C
> Program received signal SIGINT, Interrupt.
> 0x000002000007842c in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> (gdb) where
> #0 0x000002000007842c in bfd_elf64_archive_slurp_armap () from
> /usr/lib/libbfd-2.17.so
> #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd-
> 2.17.so
> #2 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd-
> 2.17.so
> #3 0x0000000128629240 in ?? ()
> warning: Hit heuristic-fence-post without finding enclosing function for
> address 0x128629240
> This warning occurs if you are debugging a function without any symbols
> (for example, in a stripped executable). In that case, you may wish to
> increase the size of the search with the `set heuristic-fence-post'
> command.
>
> Otherwise, you told GDB there was a function where there isn't one, or
> (more likely) you have encountered a bug in GDB.
> #4 0x0000000128629240 in ?? ()
> warning: Hit heuristic-fence-post without finding enclosing function for
> address 0x128629240
> Previous frame identical to this frame (corrupt stack?)
> (gdb)
>
>
>
> --
> To UNSUBSCRIBE, email to debian-alpha-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
Reply to: