From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14146 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl can't handle gold's STB_LOCAL TLS symbols Date: Sat, 25 May 2019 11:18:16 +0200 Message-ID: <20190525091816.GJ16415@port70.net> References: <20190524011204.GE23599@brightrain.aerifal.cx> 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="164097"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14162-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 25 11:18:32 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 1hUSoy-000gY8-Fy for gllmg-musl@m.gmane.org; Sat, 25 May 2019 11:18:32 +0200 Original-Received: (qmail 11420 invoked by uid 550); 25 May 2019 09:18:29 -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 11402 invoked from network); 25 May 2019 09:18:28 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190524011204.GE23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14146 Archived-At: * 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 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. i think allowing plt relocs for local syms can have unexpected effects, so i don't think that would work reliably (on systems that support lazy binding, ifuncs ldaudit and various other plt related hacks). [1] http://www.sco.com/developers/gabi/latest/ch4.symtab.html#visibility