This is the mail archive of the
ecos-bugs@sources.redhat.com
mailing list for the eCos project.
[Bug 1000031] GCC linker crashes with included object file
- From: bugzilla at ecoscentric dot com
- To: ecos-bugs at sources dot redhat dot com
- Date: Tue, 15 Jul 2003 05:20:21 +0100 (BST)
- Subject: [Bug 1000031] GCC linker crashes with included object file
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000031
jifl@ecoscentric.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From jifl@ecoscentric.com 2003-15-07 05:20 BST -------
I've had a look at this now myself. LD segfaults obviously, but the SEGV is in
malloc which isn't useful in itself.
Linking LD with electric fence I see the source of the problem is:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 27745)]
0x08077af8 in _bfd_elf32_gc_record_vtentry (abfd=0x404b0f64, sec=0x404d13ac,
h=0x404cd028, addend=64) at
/home/jlarmour/sourceware/binutils/binutils-2_13_2_1/bfd/elflink.h:8144
8144 h->vtable_entries_used[addend / file_align] = true;
(gdb) bt
#0 0x08077af8 in _bfd_elf32_gc_record_vtentry (abfd=0x404b0f64, sec=0x404d13ac,
h=0x404cd028, addend=64)
at /home/jlarmour/sourceware/binutils/binutils-2_13_2_1/bfd/elflink.h:8144
#1 0x0806b219 in elf32_arm_check_relocs (abfd=0x404b0f64, info=0x80bcca0,
sec=0x404d13ac, relocs=0x404d88cc)
at /home/jlarmour/sourceware/binutils/binutils-2_13_2_1/bfd/elf32-arm.h:2836
#2 0x08070307 in elf_link_add_object_symbols (abfd=0x404b0f64, info=0x80bcca0)
at /home/jlarmour/sourceware/binutils/binutils-2_13_2_1/bfd/elflink.h:2199
#3 0x0804f6d1 in load_symbols (entry=0x402c6cc0, place=0xbfffe490) at
/home/jlarmour/sourceware/binutils/binutils-2_13_2_1/ld/ldlang.c:1589
#4 0x0804ff9a in open_input_bfds (s=0x402c6cc0, force=false) at
/home/jlarmour/sourceware/binutils/binutils-2_13_2_1/ld/ldlang.c:1993
#5 0x080526ad in lang_process () at
/home/jlarmour/sourceware/binutils/binutils-2_13_2_1/ld/ldlang.c:4226
#6 0x08054d1d in main (argc=1, argv=0xbfffe554) at
/home/jlarmour/sourceware/binutils/binutils-2_13_2_1/ld/ldmain.c:406
#7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
So yes it's indeed to do with vtables. g->vtable_entries_used[16] appears to be
some other bit of memory it isn't a boolean like it's meant to be).
I can only really suggest you report this to the binutils project as a bug since
this would take a fair bit of debugging to work out what's going wrong (along
with a much simpler test case in source form).
But obviously, if -fno-vtable-gc works for you then definitely do that. It's a
space saving optimisation only, and may not affect any code. In fact I know it
doesn't affect eCos code itself as no code in eCos has vtables.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.