From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14143 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ryan Prichard Newsgroups: gmane.linux.lib.musl.general Subject: musl can't handle gold's STB_LOCAL TLS symbols Date: Thu, 23 May 2019 17:47:13 -0700 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c0b63d0589978a72" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="181956"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14159-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 24 02:47:42 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hTyN3-000lEZ-DD for gllmg-musl@m.gmane.org; Fri, 24 May 2019 02:47:41 +0200 Original-Received: (qmail 25787 invoked by uid 550); 24 May 2019 00:47:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 25745 invoked from network); 24 May 2019 00:47:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TImYhtzF82pp6r75BloT0Wb7unczmCwNYivFfj0uEBg=; b=AmrZVMnEpSpsMHnssnZtRXo/MpD3w6sNnwU7uUlMv1TNMqYAoYINZQST8tVaoCdKjW /ig9FX5PgN1V8c1TRdkFlT5tY8svDKrHqc3GvH0iMAlkiZm34O09YGJxFYyvRD93dyvQ bjxNfW/NG5f2fN0dKUDzfddiTIb0tYJveI5h7aqrhdQbzqrRy5yK6slLrUCyKph/c0Uo gKZ+UVszEjELSsoVn4F/X2BArdYx15R9hrb8xp+q115T9YKLv4ogTb8EvEEAJX+vYlzc c56BCWO0lntW1upTf2gZivbj1MgT8B6gKe5xObKI4ixYOw+Fog7x2dfh8najCalmOGwA 4mHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TImYhtzF82pp6r75BloT0Wb7unczmCwNYivFfj0uEBg=; b=sB7ddsSiQn+ZMSAEw4PVoS2fWQrxFKBj4v0UNKMVe48I+dBL2tjSs83kkWXu5mI147 d4L2JeG7ooYyENM0F9Jj77X9k6fuMKEjsR26euHGjNGZcxyAe9sZejtyepkzrLdGD6dQ iuARtWo7fcImvmb3mT0+Du3abe0GgtYuy9b2IiAhw/t08bs+v8Jzn2iDQJGqy43yhuWO h10Q9BOCPbm5hN6g9TZ9MEofX/XQ8P6+AHOx0tHQXSkcBWfGdAKjxMeYCvF+zhk8EaJq wSnM5nwMbM0Uh91EzSdC2b+EQLjtCsPfGIG/9NbwG/5bL8GHgoksYnkORY3nMvcAx1YO edaw== X-Gm-Message-State: APjAAAVPUtNXc28nQC2kiByTyC2luqtGuoOEDwU5ngjKTEMiTrewmPGe C7VeOlilC0+n+hTDN07Sdg2MejTD3x+KZef/gJIL+5AsjIA= X-Google-Smtp-Source: APXvYqwIQ6lfe8LCOuqzO19Oth81Ahqlnsigpeaj5cKYHf2WDrf5+ueHstS3eiFrss1CBjd7OqohnzWTGXc5HoiCRIE= X-Received: by 2002:a1c:c00b:: with SMTP id q11mr2005050wmf.4.1558658844471; Thu, 23 May 2019 17:47:24 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:14143 Archived-At: --000000000000c0b63d0589978a72 Content-Type: text/plain; charset="UTF-8" I noticed that if I use a version script with ld.gold to make a TLS symbol in a DSO local, the symbol remains in the .dynsym table but with local binding. Gold emits DTPMOD/DTPOFF relocations to the local TLS symbol, and when musl tries to load the DSO, it apparently tries to look up the symbol name globally and fails. $ cat vers { global: get_tls_var; local: *; }; $ cat dso.c __thread int tlsvar; int get_tls_var(void) { return tlsvar; } $ cat main.c int get_tls_var(void); int main() { get_tls_var(); return 0; } $ musl-gcc dso.c -fpic -shared -fuse-ld=gold -Wl,-version-script=vers -o libdso.so $ musl-gcc main.c libdso.so -Wl,-rpath,'$ORIGIN' -o main $ ./main Error relocating /tmp/local-tls-symbol/libdso.so: tlsvar: symbol not found Error relocating /tmp/local-tls-symbol/libdso.so: tlsvar: symbol not found $ readelf -rW --dyn-syms libdso.so ... 0000000000001fd8 0000000100000010 R_X86_64_DTPMOD64 0000000000000000 tlsvar + 0 0000000000001fe0 0000000100000011 R_X86_64_DTPOFF64 0000000000000000 tlsvar + 0 ... 1: 0000000000000000 4 TLS LOCAL DEFAULT 13 tlsvar ... The test program works with ld.bfd, because ld.bfd converts the DTPMOD relocation to 0 and omits the DTPOFF relocation. There was a somewhat similar issue with gold+musl involving a DTPMOD relocation to a local section symbol, https://sourceware.org/bugzilla/show_bug.cgi?id=17699. That issue prompted a thread on the generic-abi group, https://groups.google.com/d/topic/generic-abi/dJ4_Y78aQ2M/discussion. I'm wondering if this problem is a bug in musl or gold. I also wonder if DTPOFF can reference a TLS section, even though the value of a TLS section symbol isn't suitable for DTPOFF unless it's first adjusted by the segment's p_vaddr. -Ryan --000000000000c0b63d0589978a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I noticed that if I use a version script with ld.gold to m= ake a TLS symbol in a DSO local, the symbol remains in the .dynsym table bu= t with local binding. Gold emits DTPMOD/DTPOFF relocations to the local TLS= symbol, and when musl tries to load the DSO, it apparently tries to look u= p the symbol name globally and fails.

$ cat vers
{global:
=C2=A0 get_tls_var;
local:
=C2=A0 *;
};

$ cat dso.c
__thread int tlsvar;
int get_tls_var(voi= d) {
=C2=A0 return tlsvar;
}

$ cat main.= c
int get_tls_var(void);
int main() {
=C2=A0 get_tls_var();
= =C2=A0 return 0;
}

$ musl-gcc dso.c -fpic -= shared -fuse-ld=3Dgold -Wl,-version-script=3Dvers -o libdso.so
$=C2=A0musl-gcc main.c libdso.so -Wl,-rpath,'$ORIGIN' -o main
$ ./main
Error relocating /tmp/local-tls-symbol/libdso.so: tlsvar= : symbol not found
Error relocating /tmp/local-tls-symbol/libdso.so: tls= var: symbol not found

$ readelf -rW --dyn-syms= libdso.so
...
0000000000001fd8 =C2=A00000000100000010 R_X86_64_DTPM= OD64 =C2=A0 =C2=A0 =C2=A00000000000000000 tlsvar + 0
0000000000001fe0 = =C2=A00000000100000011 R_X86_64_DTPOFF64 =C2=A0 =C2=A0 =C2=A000000000000000= 00 tlsvar + 0
...
=C2=A0 =C2=A0 =C2=A01: 0000000000000000 =C2=A0 =C2= =A0 4 TLS =C2=A0 =C2=A0 LOCAL =C2=A0DEFAULT =C2=A0 13 tlsvar
= ...

The test program works with ld.bfd, because=C2= =A0ld.bfd converts the DTPMOD relocation to 0 and omits the DTPOFF relocati= on. There was a somewhat similar issue with gold+musl involving a DTPMOD re= location to a local=C2=A0section symbol,=C2=A0https://sourceware.org/bugzilla/show= _bug.cgi?id=3D17699. That issue prompted a thread on the generic-abi gr= oup,=C2=A0https://groups.google.com/d/topic/generic-abi/dJ4_Y78aQ2M/d= iscussion.

I'm wondering if this problem i= s a bug in musl or gold. I also wonder if DTPOFF=C2=A0can reference a TLS s= ection, even though the value of a TLS section symbol isn't suitable fo= r DTPOFF unless it's first adjusted by the segment's p_vaddr.
=

-Ryan

--000000000000c0b63d0589978a72--