From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13587 Path: news.gmane.org!.POSTED!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_key_create bug? Date: Tue, 8 Jan 2019 17:40:41 -0500 Message-ID: <20190108224041.unjv3ml45vs3ljdw@midipix.org> References: <84B22C11-AA93-47FD-8352-A4F18B19F689@gmail.com> <5c1d9cf6-1b53-7082-5dee-8673ed4c55e9@adelielinux.org> <20190107021128.GW23599@brightrain.aerifal.cx> <20190107171327.GD29911@voyager> <20190108000018.GZ23599@brightrain.aerifal.cx> <20190108084310.GD4305@example.net> <20190108193454.GE29911@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: blaine.gmane.org 1546987140 4000 195.159.176.226 (8 Jan 2019 22:39:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2019 22:39:00 +0000 (UTC) User-Agent: NeoMutt/20180716 To: musl@lists.openwall.com Original-X-From: musl-return-13603-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 08 23:38:56 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.84_2) (envelope-from ) id 1gh01Q-0000wH-Jd for gllmg-musl@m.gmane.org; Tue, 08 Jan 2019 23:38:56 +0100 Original-Received: (qmail 23660 invoked by uid 550); 8 Jan 2019 22:41:05 -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 23642 invoked from network); 8 Jan 2019 22:41:05 -0000 Content-Disposition: inline In-Reply-To: <20190108193454.GE29911@voyager> X-CMAE-Envelope: MS4wfIaDtBw6+S5mWwt6oP9OTJFw5SmBMehLIEqhH7ocitg6iN/YWdkhcjfAyQi2djPV+D/MWXCyb48qQzfPPZpNWHnSrwZdt/LDTRdOV5e4CPHIet1ZNFtz gTZZP+EOWnZ/c7LR1dBM6hDNqFoMdbuysDeY3pAipePQOw5xp6CJjiz6I4Hi5dvOhyQnVaHYBZzAVw== Xref: news.gmane.org gmane.linux.lib.musl.general:13587 Archived-At: On 01/08/2019 20:34, Markus Wichmann wrote: > On Tue, Jan 08, 2019 at 09:43:10AM +0100, u-uy74@aetey.se wrote: > > On Mon, Jan 07, 2019 at 07:00:18PM -0500, Rich Felker wrote: > > > > > > > > +extern hidden weak void __pthread_key_delete_synccall(void (*f)(void *), void *p); > > > > > musl on the basis (perhaps somewhat dubious) that they're an > > > additional toolchain feature that might cause problems reusing the > > > code in non-ELF contexts (this may affect midipix; I'm not sure). > > > > Thanks. That's no doubt, the less the reliance on toolchain features, > > the easier to use, especially in the ways/areas not known in advance. > > > > Rune > > > > Well, what happens on midipix with this patch? Worst case scenario is, > the toolchain doesn't do weak references, and the reference becomes > strong. So that would leave you no worse than the current situation. Or > am I missing the point? Weak/hidden symbols and references as used in the patch are actually supported. Generally speaking, default visibility means that a register (say, rax) is going to have the address of a function's .got entry (.got entries in PE are specific to midipix and are part of the toolchain's customization), and the call will thus take the form of callq *%rax. With hidden visibility, rax would contain the actual function address, and the call would accordingly become callq %rax. Weak references on midipix provide most of everything that ELF provides. With your patch applied, and linking libc.so with pthread_key_delete.lo (and thus also tss_delete.lo) left out, the resuling image contains the following as expected (callq 0 being the bit of interest): 6bc4d0f3: 48 8d 0d 46 c7 00 00 lea 0xc746(%rip),%rcx # 6bc59840 6bc4d0fa: 48 89 44 24 20 mov %rax,0x20(%rsp) 6bc4d0ff: c7 44 24 28 0b 00 00 movl $0xb,0x28(%rsp) 6bc4d106: 00 6bc4d107: e8 f4 2e 3b 94 callq 0 <__dll__> To complete the picture, the one weak/hidden trick that's currently not supported on midipix consists in musl's src/errno/__errno_location.c and src/include/errno.h, where you end up with "call ___errno_location" (because of the hidden attribute) in many translation units, yet a strongly defined ___errno_location in none (for which the workaround is to provide a strong ___errno_location() function). > > Ciao, > Markus > --