mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Frediano Ziglio <fziglio@redhat.com>
To: musl@lists.openwall.com
Subject: Re: Does TD point to itself intentionally?
Date: Sat, 30 Mar 2019 09:18:08 -0400 (EDT)	[thread overview]
Message-ID: <43572387.10269431.1553951888420.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20190330125731.GC18043@voyager>

> 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


  reply	other threads:[~2019-03-30 13:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30 10:38 Markus Wichmann
2019-03-30 11:11 ` Frediano Ziglio
2019-03-30 12:57   ` Markus Wichmann
2019-03-30 13:18     ` Frediano Ziglio [this message]
2019-03-30 14:39 ` Rich Felker
2019-03-30 16:36   ` Markus Wichmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43572387.10269431.1553951888420.JavaMail.zimbra@redhat.com \
    --to=fziglio@redhat.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).