From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14147 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl can't handle gold's STB_LOCAL TLS symbols Date: Sat, 25 May 2019 12:51:33 -0400 Message-ID: <20190525165133.GF23599@brightrain.aerifal.cx> References: <20190524011204.GE23599@brightrain.aerifal.cx> <20190525091816.GJ16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="36226"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14163-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 25 18:51:49 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 1hUZtd-0009JN-8S for gllmg-musl@m.gmane.org; Sat, 25 May 2019 18:51:49 +0200 Original-Received: (qmail 30614 invoked by uid 550); 25 May 2019 16:51:46 -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 30593 invoked from network); 25 May 2019 16:51:46 -0000 Content-Disposition: inline In-Reply-To: <20190525091816.GJ16415@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14147 Archived-At: On Sat, May 25, 2019 at 11:18:16AM +0200, Szabolcs Nagy wrote: > * Rich Felker [2019-05-23 21:12:04 -0400]: > > On Thu, May 23, 2019 at 05:47:13PM -0700, Ryan Prichard wrote: > > > 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 > > > > I would consider this a bug in gold. There is no reason to leave local > > symbols unresolved until runtime; resolving them is ld's whole job. > > > > > 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. > > > > I don't see a good reason for it to reference a section either. It > > should just have a 0 symbol reference, and store the ld-determined > > offset to the object in the addend. Any kind of symbolic reference > > here is just going to be a waste of time doing a lookup at runtime. > > the sysv elf spec allows leaving STB_LOCAL symbols > in the dynamic symbol table if they were hidden [1]. > it does not say if symbolic dynamic relocs may refer > to them, though. I don't think there's any reasonable way a reference to the symbol from a relocation can distinguish between one that needs to use the local definition and one that needs to follow normal global symbol resolution, is there? Or can it just skip the lookup entirely and use the reference as the definition in this case?? If that's possible it might be trivial and non-controversial to support. > i think it should not be too hard to adjust > do_relocs to handle this, not sure about do_dlsym. > current dlsym does not seem to check OK_BIND > so a local sym may preempt a global one. This is a bug we need to fix. It was probably fixed by your old patch to unify symbol lookup paths, but that bitrotted before it ever got applied. Rich