| Summary: | ld segfault in bfd_hash_allocate | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Ralf Corsépius <ralf.corsepius> |
| Component: | ld | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug-binutils, hjl.tools, joel.sherrill |
| Priority: | P2 | ||
| Version: | 2.21 | ||
| Target Milestone: | --- | ||
| Host: | x86_64-unknown-linux-gnu | Target: | powerpc-rtems*, powerpc-elf* |
| Build: | Last reconfirmed: | ||
| Attachments: |
data to reproduce the report
A kludge |
||
Created attachment 4947 [details]
data to reproduce the report
Extract the tarball and try
# powerpc-rtems4.11-ld -o minimum.ralf bootloader.o -b binary rtems.gz \
-T ppcboot.lds
There is a fundamental problem in ld: 1. Different formats, ELF, COFF, XCOFF, ... have different linker hash table and its entry. 2. It works as long as input and output have the same format. 3. When input format != output format, output linker hash table and its entry have different formats from the ones used by input. We can't use output linker hash table on input in this case. We have been lucky most of time. This bug isn't one of them. Created attachment 4950 [details]
A kludge
This is a kludge.
Subject: Bug 11939 CVSROOT: /cvs/src Module name: src Changes by: hjl@sourceware.org 2010-08-25 20:35:59 Modified files: bfd : ChangeLog elflink.c Log message: Don't set unique_global for non-ELF hash link table. 2010-08-25 H.J. Lu <hongjiu.lu@intel.com> PR ld/11939 * elflink.c (elf_link_add_object_symbols): Don't set unique_global for non-ELF hash link table. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5117&r2=1.5118 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.375&r2=1.376 Fixed. Thanks, your "kludge" seems to be working fine! |
I am facing a segfault with powerpc-rtems*ld (powerpc-rtems is almost identical to powerpc-*elf): # powerpc-rtems4.11-ld -o minimum.ralf bootloader.o -b binary rtems.gz \ -T ppcboot.lds Segmentation fault (core dumped) gdb-traceback: #0 _int_malloc (av=0x3a2ab7ae80, bytes=<value optimized out>) at malloc.c:4439 #1 0x0000003a2a879a3d in __libc_malloc (bytes=4064) at malloc.c:3660 #2 0x00000000004e8a74 in _objalloc_alloc (o=0x2408390, len=72) at ../../libiberty/objalloc.c:152 #3 0x000000000043b2bf in bfd_hash_allocate (table=0x2408340, size=72) at ../../bfd/hash.c:571 #4 0x000000000043bd32 in _bfd_generic_link_hash_newfunc (entry=0x0, table=0x2408340, string=0x2425411 "em86_trap") at ../../bfd/linker.c:682 #5 0x000000000043aeb7 in bfd_hash_insert (table=0x2408340, string=0x2425411 "em86_trap", hash=127581402) at ../../bfd/hash.c:483 #6 0x000000000043ae87 in bfd_hash_lookup (table=0x2408340, string=0x2425411 "em86_trap", create=1, copy=0) at ../../bfd/hash.c:470 #7 0x000000000043b900 in bfd_link_hash_lookup (table=0x2408340, string=0x2425411 "em86_trap", create=1, copy=0, follow=0) at ../../bfd/linker.c:501 #8 0x000000000043ce0a in _bfd_generic_link_add_one_symbol (info=0x75a6c0, abfd=0x2412260, name=0x2425411 "em86_trap", flags=2, section=0x2414758, value=46640, string=0x0, copy=0, collect=0, hashp=0x2421c08) at ../../bfd/linker.c:1567 #9 0x000000000047c3f3 in elf_link_add_object_symbols (abfd=0x2412260, info=0x75a6c0) at ../../bfd/elflink.c:4146 #10 0x000000000047e62e in bfd_elf_link_add_symbols (abfd=0x2412260, info=0x75a6c0) at ../../bfd/elflink.c:5097 #11 0x000000000040f398 in load_symbols (entry=0x23fa0b0, place=0x7fff7881fe90) at ../../ld/ldlang.c:2707 #12 0x000000000040fe95 in open_input_bfds (s=0x23fa0b0, force=0) at ../../ld/ldlang.c:3138 #13 0x000000000041588b in lang_process () at ../../ld/ldlang.c:6287 #14 0x0000000000419726 in main (argc=9, argv=0x7fff78820058) at ../../ld/ldmain.c:455 Further info: * I am able to deterministically reproduce it on fedora-13-x86_64, but am not able to reproduce it on fedora-13-i386 nor on fedora-12-{i386,x86_64}. * I am able to reproduce the bug with ld from binutils-2.20.1, binutils-2_20-branch and from binutils CVS-HEAD. * The traceback above was produced by: # powerpc-rtems4.11-ld --version GNU ld (GNU Binutils) 2.20.1.20100822