From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13633
Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail
From: Florian Weimer <fweimer@redhat.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Symbol versioning approximation trips on compat symbols
Date: Mon, 21 Jan 2019 18:57:53 +0100
Message-ID: <87r2d5evvi.fsf@oldenburg2.str.redhat.com>
Reply-To: musl@lists.openwall.com
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228";
	logging-data="181469"; mail-complaints-to="usenet@ciao.gmane.org"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
To: musl@lists.openwall.com
Original-X-From: musl-return-13649-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 21 18:58:11 2019
Return-path: <musl-return-13649-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by ciao.gmane.org with smtp (Exim 4.89)
	(envelope-from <musl-return-13649-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1gldpq-000l9h-Bj
	for gllmg-musl@m.gmane.org; Mon, 21 Jan 2019 18:58:10 +0100
Original-Received: (qmail 5735 invoked by uid 550); 21 Jan 2019 17:58:08 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 5700 invoked from network); 21 Jan 2019 17:58:07 -0000
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 21 Jan 2019 17:57:55 +0000 (UTC)
Xref: news.gmane.org gmane.linux.lib.musl.general:13633
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/13633>

On what appears to be current Alpine Linux (musl-1.1.19-r10), the
following reproducer

######################################################################
cat > symver.c <<EOF
void
compat_function (void)
{
}
__asm__ (".symver compat_function,compat_function@SYMVER");

void
call_compat_function (void)
{
  return compat_function ();
}
EOF

echo "SYMVER { };" > symver.map

cat > main.c <<EOF
extern void call_compat_function (void);

int
main (void)
{
  call_compat_function ();
}
EOF

gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
gcc -Wl,--rpath=. -o main main.c symver.so
######################################################################

fails with:

$ ./main
Error relocating ./symver.so: compat_function: symbol not found

The problem is the compatibility symbol (one @ instead of @@).  The
dynamic linker is supposed to ignore the difference between the two, the
default vs non-default version only matters to the link editor when
processing an undefined symbol without a symbol version.

In my case, I do not need symbol interposition and therefore can work
around this, but I wonder if there is some sort of approved compile-time
or link-time check to detect this issue.  Unfortunately, the Alpine
Linux toolchain (and part of the system) is built *with* symbol
versioning support, so this does not appear to be straightforward.

The actual application does not need to make the symbol interposable, so
I can use a hidden alias within the DSO for PLT avoidance (and more
configure checks to disable all this on targets which do not support
*that*).

Thanks,
Florian