From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14038 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Does TD point to itself intentionally? Date: Sat, 30 Mar 2019 13:57:32 +0100 Message-ID: <20190330125731.GC18043@voyager> References: <20190330103814.GB18043@voyager> <1118753729.10268513.1553944301658.JavaMail.zimbra@redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153284"; 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-14054-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 30 13:57:58 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 1hADYb-000dlh-RO for gllmg-musl@m.gmane.org; Sat, 30 Mar 2019 13:57:57 +0100 Original-Received: (qmail 11335 invoked by uid 550); 30 Mar 2019 12:57:55 -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 11312 invoked from network); 30 Mar 2019 12:57:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553950663; bh=n0V5bSvuGGJA41jA5TE02LJtAptp9G1WvVLbgQHVSPI=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=L2LdpRfjZtJ72dpY/thKNK+bq1o8MJoIN8uZeMaNJRV+TUgp8EIk+p0ZOyHWVn/Lo g2rFdr8iQ1US4xDJu8RPcgQN1cu5qvdsGne1cUntpOfB732Q/K/zue4GF/TvRysdlQ w37vHfaxXP+vpPf9RW0x1yDxm3JpENx1RbtTdxRE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: <1118753729.10268513.1553944301658.JavaMail.zimbra@redhat.com> X-Provags-ID: V03:K1:jqrTWZnyaqF+oj8fDGFUfuc58qA0kB8tMQMJd5KXZwSmPDZG9x8 gyKyQ9CAHMaZCrjdWMuYOkiAZYGpJLvmKtycet7nYOYXEm6LmkEw+mlkoR04AGx3mrmMkJV 1QU2RhNE3eGXIsaUw63yRXMeROrRIhyAlgLaI+lq3IFF5blPPdzDZ0p9rPIDn7MsJm0Xg1u oFcF7zgXE1jZSJgZ9m3JA== X-UI-Out-Filterresults: notjunk:1;V03:K0:awF51eurwyA=:8ofnDmZ/iXgZxQyGI8sBb9 onK+wUZ4Bj5Ex1yJdsoFUtUIH24MmCaxJwffzGcTltYA5oPb4yc4xRsbyo0Fs5RgcjJqsNovY SRxjLBYsG9doelFrpqKmCu0VJAHKuQbBCJJ9J7skCA5rfXas2uqGBRakHAMK1HT4RP+M4a1OI NjB5Ey8DytSuqg09BxlpKjbyvbSqXBq8tK4TcMWlVbanWImKS7OQ4IzHGU3AxRDbFBwBGtjmJ VUX/6I6lqy3gDcF5MU6YpEi7nWXmuY/8MaR48Uf++hRrazlDRcXS1s30rGO68/mi5gKNDKztJ UhkFFd85cSB3/m99yF0iIF+2K87KemaLzjrlbMIixjW4JWp3AesAN8E93rhWVJq9pAmnBzVnK nYt1AuWoKEewxnT10OcSKAnTT4V05+MIuzuaJql/pONuATMXZhiT4p+V25zAfIm3EEy8vT0wy y4O7f2xEPxoXHYrViUNql2x7UdGMg3pqI4JcVOjIL2RVYZXPHchaS9/lAVE6/g48YytBVtm2b xyAEwSV///wIm/M+1HPwuSvC3n/Mpm3yD4R2ugmLXIYi4UZ16yQ6HGotqD11m0Swq4akDE5Vq ExxJ7lrhmMeMvsbvjpRxqjAauG5vdX1/KaMaPG0VJVUeqBCcStAjWwDIZq91J+OkTUtaxFz4M QxzsLIG6FDvH7c2TgoqreERfRYL7ba43eG30Yyg1xNaFiGnKsczOvXbUQBk8Xc+iQkyz4Lgim a8IKYLF8rcfbkjiDn0gvmQ28NN7ZW8OQQK8niYuGQDN2pgHoaUMw6IBGPeY0mvQ/BCgN7YWb Xref: news.gmane.org gmane.linux.lib.musl.general:14038 Archived-At: On Sat, Mar 30, 2019 at 07:11:41AM -0400, Frediano Ziglio wrote: > But "lea" how? It would be a rdfsbase instruction as "standard" register= s > are used for other purposes. But as you said you cannot assume rdfsbase = would > work so it's hard to inline it. Doing that way you can inline that singl= e > assembly instruction easily. > > Frediano I don't understand the objection. I was talking about replacing __pthread_self() with: asm ("lea %%fs:0, %0" : "=3Dr"(self)); In case you are unfamilliar with that instruction: If the %0 were replaced with %rax, this would assemble to the opcode: 64 40 8d 04 25 00 00 00 00 My god... having written this down, it would apparently be cheaper (code size wise) to encode xorl %eax,%eax leaq %fs:(%rax),%rax Because in 64-bit mode you need a SIB byte to encode absolute addresses, and the SIB byte in this mode only does 32-bit displacements. Let's see... 31 C0 64 40 8d 00 Yep. 9 bytes vs. 6 bytes. But now I'm micro-optimizing. Though this optimization would also be valid for the current implementation. Something like: static inline struct pthread *__pthread_self() { #ifdef MY_PATCH #define INST "lea" #else #define INST "mov" #endif struct pthread *self =3D 0; __asm__ (INST " %%fs:0,%0" : "+r" (self) ); return self; } My question was more about removing this conceptual hurdle, and making it more clear that FS indeed points to the thread descriptor, and not a pointer to the thread descriptor. I know full well we can't remove "self", nor skip the initialization, since both of these are ABI. Ciao, Markus