From binutils-return-16804-listarch-binutils=sourceware dot cygnus dot com at sources dot redhat dot com Wed Mar 27 05:45:35 2002 Return-Path: Delivered-To: listarch-binutils at sourceware dot cygnus dot com Received: (qmail 30835 invoked by alias); 27 Mar 2002 05:45:34 -0000 Mailing-List: contact binutils-help at sources dot redhat dot com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner at sources dot redhat dot com Delivered-To: mailing list binutils at sources dot redhat dot com Received: (qmail 30796 invoked from network); 27 Mar 2002 05:45:32 -0000 Received: from unknown (HELO mta04bw.bigpond.com) (139.134.6.87) by sources dot redhat dot com with SMTP; 27 Mar 2002 05:45:32 -0000 Received: from bubble.local ([144.135.24.72]) by mta04bw dot bigpond dot com (Netscape Messaging Server 4 dot 15) with SMTP id GTMANU00 dot AT6 for ; Wed, 27 Mar 2002 15:45:30 +1000 Received: from CPE-144-136-176-14.sa.bigpond.net.au ([144.136.176.14]) by bwmam02.mailsvc.email.bigpond.com(MailRouter V3.0i 17/288939); 27 Mar 2002 15:45:30 Received: (qmail 21350 invoked by uid 179); 27 Mar 2002 05:45:34 -0000 Date: Wed, 27 Mar 2002 16:15:34 +1030 From: Alan Modra To: David O'Brien Cc: binutils at sources dot redhat dot com Subject: Re: ld i386 differences 2.10.2 / 2.12 Message-ID: <20020327054534.GP18838@bubble.sa.bigpond.net.au> Mail-Followup-To: David O'Brien , binutils at sources dot redhat dot com References: <20020325153403.96899.qmail@web11803.mail.yahoo.com> <20020326060951.GA18838@bubble.sa.bigpond.net.au> <20020326145254.B58114@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020326145254 dot B58114 at dragon dot nuxi dot com> User-Agent: Mutt/1.3.25i On Tue, Mar 26, 2002 at 02:52:54PM -0800, David O'Brien wrote: > > The bug appears to be triggered when compiling a dynamic binary (does not > happen when 'cc -static' is used) using GCC 2.95.4 in code that uses this > macro: > > #define __warn_references(sym,msg) \ > __asm__(".section .gnu.warning." #sym); \ > __asm__(".asciz \"" msg "\""); \ > __asm__(".previous") > > If I use bfd/elf32-i386.c rev 1.51 rather than 1.52 (reset of files -D > '9/29/2001 06:22:00 UTC') I do not get the segfault. This one was a little tricky. See the comment in the patch. * elf32-i386.c (allocate_dynrelocs): Follow warning symbol link. In fact, I'm going to think about this for a while before applying, because I think we may have a bug in elf_adjust_dynamic_symbol too. That may be a better place to correct the problem. (gdb) p *h $3 = {root = {root = {next = 0x0, string = 0x8133bc0 "mktemp", hash = 100717032}, type = bfd_link_hash_warning, next = 0x0, u = { undef = {abfd = 0x8162728}, def = {value = 135669544, section = 0x0}, i = {link = 0x8162728, warning = 0x0}, c = {size = 135669544, p = 0x0}}}, indx = -1, dynindx = -1, dynstr_index = 0, elf_hash_value = 0, weakdef = 0x0, linker_section_pointer = 0x0, verinfo = { verdef = 0x0, vertree = 0x0}, vtable_entries_size = 0, vtable_entries_used = 0x0, vtable_parent = 0x0, got = {refcount = 0, offset = 0}, plt = {refcount = 0, offset = 0}, size = 0, type = 0 '\0', other = 0 '\0', elf_link_hash_flags = 273} h->elf_link_hash_flags == (ELF_LINK_NON_ELF | ELF_LINK_HASH_REF_REGULAR_NONWEAK | ELF_LINK_HASH_REF_REGULAR) (gdb) p *((struct elf_link_hash_entry *) h->root.u.i.link) $4 = {root = {root = {next = 0x0, string = 0x8133bc0 "mktemp", hash = 100717032}, type = bfd_link_hash_defined, next = 0x8162728, u = { undef = {abfd = 0xa0}, def = {value = 160, section = 0x813b384}, i = { link = 0xa0, warning = 0x813b384 "\213;\023\bf"}, c = {size = 160, p = 0x813b384}}}, indx = -1, dynindx = 15, dynstr_index = 16, elf_hash_value = 0, weakdef = 0x0, linker_section_pointer = 0x0, verinfo = { verdef = 0x0, vertree = 0x0}, vtable_entries_size = 0, vtable_entries_used = 0x0, vtable_parent = 0x0, got = {refcount = 0, offset = 0}, plt = {refcount = 0, offset = 0}, size = 19, type = 2 '\002', other = 0 '\0', elf_link_hash_flags = 6} here, elf_link_hash_flags == (ELF_LINK_HASH_REF_DYNAMIC | ELF_LINK_HASH_DEF_REGULAR) -- Alan Modra IBM OzLabs - Linux Technology Centre Index: bfd/elf32-i386.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-i386.c,v retrieving revision 1.65 diff -u -p -r1.65 elf32-i386.c --- elf32-i386.c 2002/02/19 12:40:23 1.65 +++ elf32-i386.c 2002/03/27 05:32:01 @@ -1251,9 +1250,14 @@ allocate_dynrelocs (h, inf) struct elf_i386_link_hash_entry *eh; struct elf_i386_dyn_relocs *p; - if (h->root.type == bfd_link_hash_indirect - || h->root.type == bfd_link_hash_warning) + if (h->root.type == bfd_link_hash_indirect) return true; + + if (h->root.type == bfd_link_hash_warning) + /* When warning symbols are created, they **replace** the "real" + entry in the hash table, thus we never get to see the real + symbol in a hash traversal. So look at it now. */ + h = (struct elf_link_hash_entry *) h->root.u.i.link; info = (struct bfd_link_info *) inf; htab = elf_i386_hash_table (info);