From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5637 invoked by alias); 2 Sep 2009 16:28:43 -0000 Received: (qmail 5628 invoked by uid 22791); 2 Sep 2009 16:28:42 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 16:28:37 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n82GSX3Y003138 for ; Wed, 2 Sep 2009 17:28:33 +0100 Received: from fxm20 (fxm20.prod.google.com [10.184.13.20]) by wpaz1.hot.corp.google.com with ESMTP id n82GSU3i012402 for ; Wed, 2 Sep 2009 09:28:30 -0700 Received: by fxm20 with SMTP id 20so957676fxm.0 for ; Wed, 02 Sep 2009 09:28:30 -0700 (PDT) Received: by 10.204.157.24 with SMTP id z24mr6899729bkw.208.1251908909879; Wed, 02 Sep 2009 09:28:29 -0700 (PDT) Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) by mx.google.com with ESMTPS id p9sm165874fkb.7.2009.09.02.09.28.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 09:28:28 -0700 (PDT) To: ramana.radhakrishnan@arm.com Cc: binutils@sourceware.org Subject: Re: Abort in elflink.c: elf_link_check_versioned_symbol References: <1251281400.4775.15.camel@e200593-lin.cambridge.arm.com> <1251895757.8812.97.camel@e200593-lin.cambridge.arm.com> From: Ian Lance Taylor Date: Wed, 02 Sep 2009 16:28:00 -0000 In-Reply-To: <1251895757.8812.97.camel@e200593-lin.cambridge.arm.com> (Ramana Radhakrishnan's message of "Wed\, 02 Sep 2009 13\:49\:17 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00068.txt.bz2 Ramana Radhakrishnan writes: >> > The symbol for which this abort happens is >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc >> > ++.so. Looking at this symbol in libstdc++.so, I can see that this is >> > versioned and weak as below but the actual symbol doesn't appear in the >> > shared object. >> > >> >>From the Symbol Table of libstdc++ >> > >> > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 >> >> That is a real symbol definition. It merely happens to be marked weak. > > Fair enough. If this is a real symbol definition and happens to be just > marked weak , then shouldn't all references resolve to this symbol. Normally yes, but based on the code path you show below the symbol has been forced to be local. That is, you are using a version script which forces this symbol to be local and therefore not visible to shared libraries. >> I think what is happening is that elf_link_check_versioned_symbol >> assumes that it will only be called when the regular symbol resolution >> code did not resolve the symbol. So it does not expect to see an >> unhidden symbol here; an unhidden symbol should already have been >> resolved. So you should find out why elf_link_check_versioned_symbol is >> being called here. > > elf_link_check_versioned_symbol is being called from the following call > stack > > Breakpoint 1, _bfd_abort (file=0xe2c18 > "/home/ramrad01/sources/src/bfd/elflink.c", line=8440, fn=0xe36f0 > "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > 928 { > (gdb) bt > #0 _bfd_abort (file=0xe2c18 "/home/ramrad01/sources/src/bfd/elflink.c", > line=8440, fn=0xe36f0 "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > #1 0x00068474 in elf_link_check_versioned_symbol (info= out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data= optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > #3 0x00039308 in bfd_hash_traverse (table=0x110578, func=0x68484 > , info=0xbeffca84) > at /home/ramrad01/sources/src/bfd/hash.c:603 > #4 0x0006f114 in bfd_elf_final_link (abfd=0x16b18, info=0x845a8) > at /home/ramrad01/sources/src/bfd/elflink.c:10588 > #5 0x0004a99c in elf32_arm_final_link (abfd=0xe2c18, info=0x20f8) > at /home/ramrad01/sources/src/bfd/elf32-arm.c:9296 > #6 0x0001ea1c in ldwrite () > at /home/ramrad01/sources/src/ld/ldwrite.c:567 > #7 0x0001de58 in main (argc=0, argv=0x9984) > at /home/ramrad01/sources/src/ld/ldmain.c:464 > (gdb) up > #1 0x00068474 in elf_link_check_versioned_symbol (info= out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > 8440 abort (); > (gdb) up > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data= optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > 8531 if (! finfo->info->relocatable > > > As you can see this is getting called from bfd_elf_final_link which ends > up calling elf_link_output_extsym where the abort happens. > > The reason that we call this in elf_link_output_extsym from the > following comment is - > > (gdb) l 8536 > 8531 if (! finfo->info->relocatable > 8532 && (! finfo->info->shared) > 8533 && h->forced_local > 8534 && h->ref_dynamic > 8535 && !h->dynamic_def > 8536 && !h->dynamic_weak > 8537 && ! elf_link_check_versioned_symbol (finfo->info, bed, > h)) > 8538 { > 8539 (*_bfd_error_handler) > 8540 (_("%B: %s symbol `%s' in %B is referenced by DSO"), > > > which appears to be correct. From what you say and looking at the code > it appears as though one might have to refactor the code accordingly - > to give errors depending on when this function is called ? I think this case in elf_link_check_versioned_symbol: if ((iver.vs_vers & VERSYM_HIDDEN) == 0) { /* If we have a non-hidden versioned sym, then it should have provided a definition for the undefined sym. */ abort (); } should simply return FALSE. You've demonstrated that this case can arise when a version script is used. Ian