From patchwork Thu Nov 27 08:16:45 2014
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Alan Modra <amodra@gmail.com>
X-Patchwork-Id: 415406
Return-Path: 
 <libc-alpha-return-54833-incoming=patchwork.ozlabs.org@sourceware.org>
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@bilbo.ozlabs.org
Received: from sourceware.org (server1.sourceware.org [209.132.180.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
	bits)) (No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPS id 66C841401DC
	for <incoming@patchwork.ozlabs.org>;
	Thu, 27 Nov 2014 19:17:21 +1100 (AEDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:mime-version
	:content-type; q=dns; s=default; b=bJrW8/88grb3HazdsIO+JgFurps9M
	SmtnKvE7vTACphCEyIyOIMcPmak7sdKddTN0X7mumaGjn5XfylFFAOYkq/ZLzbA5
	Y7D/fX6QvZ0kAxtb8+U1QyiRnN+oq1YWz8RMlWyBg26eHxhOI25w2yxxhrsyZvbk
	x+yxWo9xkyfJ/0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:mime-version
	:content-type; s=default; bh=oNVZwT5g73pUhwkBEtK8J/5vm54=; b=rvZ
	F+J9v3ZCWnI9GLVSC8X2WgQy6tKPp2yYLspsLkcLubyX/1NKQKK1ZWVOKcvWf1V6
	QQFTLL4HisgBgVmu3JGrSbllmTM1EEEeD4Hj+oY3Eg2Q+xeFpp1RNLiXK0lXvDRv
	s32LqP2YF9/+yA0v5RIcSi92U1sHq8ZaNQhR0spY=
Received: (qmail 26824 invoked by alias); 27 Nov 2014 08:16:56 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Unsubscribe: 
 <mailto:libc-alpha-unsubscribe-incoming=patchwork.ozlabs.org@sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>,
	<http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Delivered-To: mailing list libc-alpha@sourceware.org
Received: (qmail 26803 invoked by uid 89); 27 Nov 2014 08:16:55 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00,
	FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,
	SPF_PASS autolearn=ham version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: mail-pa0-f45.google.com
X-Received: by 10.69.20.42 with SMTP id gz10mr59668167pbd.91.1417076211755;
	Thu, 27 Nov 2014 00:16:51 -0800 (PST)
Date: Thu, 27 Nov 2014 18:46:45 +1030
From: Alan Modra <amodra@gmail.com>
To: binutils@sourceware.org, libc-alpha@sourceware.org
Subject: RFC: Don't output symbol version requirement for non-DT_NEEDED libs
Message-ID: <20141127081644.GA20383@bubble.grove.modra.org>
Mail-Followup-To: binutils@sourceware.org, libc-alpha@sourceware.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)

This is a fix for
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
a situation that can arise with weak references to versioned symbols
in dependent libraries.

Consider this testcase, a main that calls a weak "f", linked against a
shared library liba.so that has a dependency on libb.so where "f" is
defined as a versioned symbol.  A later revision of liba.so defines
"f" itself, without the version, and doesn't link against libb.so.
A further revision of liba.so doesn't link against libb.so and also
doesn't define "f".

cat > lib.c <<EOF
int f (void) { return 1; }
EOF
cat > lib.map <<EOF
FOO { global: f; };
EOF
cat > main.c <<EOF
int f (void) __attribute__ ((weak));
int main (void) { return f ? f() : 0; }
EOF
cat > empty.c <<EOF
EOF
gcc -o libb.so -shared -fPIC -Wl,-soname,libb.so,--version-script,lib.map lib.c
gcc -o liba.so.1 -shared -fPIC -Wl,--no-as-needed,-soname,liba.so -L. -lb
gcc -o liba.so.2 -shared -fPIC -Wl,-soname,liba.so lib.c
gcc -o liba.so.3 -shared -fPIC -Wl,-soname,liba.so empty.c
ln -sfn liba.so.1 liba.so
gcc -o pr16452 -fPIC main.c -Wl,--no-as-needed,--rpath,. -L. -la
./pr16452
echo $?
ln -sfn liba.so.2 liba.so
./pr16452
echo $?
ln -sfn liba.so.3 liba.so
./pr16452
echo $?

Currently the script output is
1
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
127
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
127

The problem here is that since binutils-2.22 we've defaulted to
--no-copy-dt-needed-entries (which was a good change despite the
number of bugreports it has generated).  So libb.so is not listed as
DT_NEEDED in the executable.  However, a version FOO from libb.so *is*
added to the executable, specifying that it came from libb.so.  When
we use rev 2 or 3 of liba.so, no libb.so is loaded and the version
check fails to find the required library.

You could argue that it's wrong for ld.so to complain about a weak
symbol version, but the ld.so check isn't being done against symbols.
ld.so is looking at .gnu.version_r, the version requirements
themselves, each possibly used by multiple symbols..

You might also argue that it's a user problem that f lost its version
in rev 2 of the testcase.  However this might be because liba.so is a
user library without any versioning and in rev 2, liba.so was linked
against a static libb.  (Typical libb in real life is libpthread.)

So, absent someone implementing a glibc fix, how about we just drop
the symbol versioning for weak symbols, when their defining library
won't be in DT_NEEDED?  Note that if "f" above was a strong symbol,
ld will still complain with "./libb.so: error adding symbols: DSO
missing from command line".

	PR 16452
	* elflink.c (_bfd_elf_link_find_version_dependencies): Exclude
	symbols from libraries that won't be listed in DT_NEEDED.
	(elf_link_output_extsym): Don't output verdefs for such symbols.

diff --git a/bfd/elflink.c b/bfd/elflink.c
index c8068c0..c964a98 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -1832,7 +1832,9 @@ _bfd_elf_link_find_version_dependencies (struct elf_link_hash_entry *h,
   if (!h->def_dynamic
       || h->def_regular
       || h->dynindx == -1
-      || h->verinfo.verdef == NULL)
+      || h->verinfo.verdef == NULL
+      || (elf_dyn_lib_class (h->verinfo.verdef->vd_bfd)
+	  & (DYN_AS_NEEDED | DYN_DT_NEEDED | DYN_NO_NEEDED)))
     return TRUE;
 
   /* See if we already know about this version.  */
@@ -9050,7 +9052,9 @@ elf_link_output_extsym (struct bfd_hash_entry *bh, void *data)
 
 	  if (!h->def_regular)
 	    {
-	      if (h->verinfo.verdef == NULL)
+	      if (h->verinfo.verdef == NULL
+		  || (elf_dyn_lib_class (h->verinfo.verdef->vd_bfd)
+		      & (DYN_AS_NEEDED | DYN_DT_NEEDED | DYN_NO_NEEDED)))
 		iversym.vs_vers = 0;
 	      else
 		iversym.vs_vers = h->verinfo.verdef->vd_exp_refno + 1;