From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14039 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Frediano Ziglio Newsgroups: gmane.linux.lib.musl.general Subject: Re: Does TD point to itself intentionally? Date: Sat, 30 Mar 2019 09:18:08 -0400 (EDT) Message-ID: <43572387.10269431.1553951888420.JavaMail.zimbra@redhat.com> References: <20190330103814.GB18043@voyager> <1118753729.10268513.1553944301658.JavaMail.zimbra@redhat.com> <20190330125731.GC18043@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238516"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14055-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 30 14:18:24 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 1hADsO-000zyY-2a for gllmg-musl@m.gmane.org; Sat, 30 Mar 2019 14:18:24 +0100 Original-Received: (qmail 27920 invoked by uid 550); 30 Mar 2019 13:18:21 -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 27897 invoked from network); 30 Mar 2019 13:18:20 -0000 In-Reply-To: <20190330125731.GC18043@voyager> X-Originating-IP: [10.33.32.2, 10.4.195.15] Thread-Topic: Does TD point to itself intentionally? Thread-Index: e7+RPqYs+6Sf4wEK6JOb56uaGC6Zqg== X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Sat, 30 Mar 2019 13:18:08 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14039 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" registers > > 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 single > > assembly instruction easily. > > > > Frediano > > I don't understand the objection. I was talking about replacing > __pthread_self() with: > > asm ("lea %%fs:0, %0" : "=r"(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 > The base is not taken into account, this will produce a 0. > 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 = 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 > Frediano