Add -mtls-use-call option to avoid %gs:0 TLS accesses.

Add -mtls-use-call option to avoid %gs:0 TLS accesses.

Adds an option to the 32-bit code generator to match the 64-bit
variant's behavior of generating calls to __nacl_read_tp rather
than fetches from %gs:0 to begin TLS access sequences.

We'll want this for the builds of newlib and libstdc++ that go into
the integrated runtime.  They have their own uses of TLS, which must
be kept separate from the user-side libc's TLS setup.  We'll reserve
%gs for the user side.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=1595

Committed: http://git.chromium.org/gitweb/?p=nacl-gcc.git;a=commit;h=3aa84df

[Mark Seaborn, 2011-04-05 06:23:44]

On 4 April 2011 15:52, <mcgrathr@chromium.org> wrote:

> Reviewers: mseaborn - please use other,
>
> Description:
> Add -mtls-use-call option to avoid %gs:0 TLS accesses.
>
> Adds an option to the 32-bit code generator to match the 64-bit
> variant's behavior of generating calls to __nacl_read_tp rather
> than fetches from %gs:0 to begin TLS access sequences.
>
> R=mseaborn@google.com
> BUG=
> TEST=
>

Looks good to me, although Evgeny or someone else from the Moscow team may
want to comment first.

Can you link to
BUG=http://code.google.com/p/nativeclient/issues/detail?id=1595
and add a bit more description about why we want this?  i.e. We plan to use
this to give the integrated runtime code separate TLS state from the
user-provided code, and this option would let us use the same trick on
x86-32 that we can already use on x86-64, which is replace __nacl_read_tp().

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[eaeltsin, 2011-04-05 10:16:10]

Please, add at least one of (khim@chromium.org, pasko, eaeltsin) to all gnu
toolchain code reviews!

At a first glance newly introduced option looks like duplication of
-mno-tls-direct-seg-refs (TARGET_TLS_DIRECT_SEG_REFS) for i386. Please provide
some details on the difference (if any :-)).

If you still need to introduce that new option, please make sure insns with
direct segment registers access are never used in your new mode (check i386.md)
and explain why.

[Mark Seaborn, 2011-04-05 15:12:20]

On 5 April 2011 03:16, <eaeltsin@google.com> wrote:

> Please, add at least one of (khim@chromium.org, pasko, eaeltsin) to all
> gnu
> toolchain code reviews!
>

Sure, this is why I CC'd you. :-)


> At a first glance newly introduced option looks like duplication of
> -mno-tls-direct-seg-refs (TARGET_TLS_DIRECT_SEG_REFS) for i386. Please
> provide
> some details on the difference (if any :-)).
>

No, -mno-tls-direct-seg-refs tells gcc to only use %gs:0 and not to use
%gs:N where N < 0 (TLS variables are accessed via negative offsets).  In
fact we already implicitly use -mno-tls-direct-seg-refs on NaCl x86-32
because NaCl is not able to set up %gs such that negative offsets work.

The purpose of the new option is to tell gcc not to use %gs at all.

Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[eaeltsin, 2011-04-05 15:37:00]

On 2011/04/05 15:12:20, Mark Seaborn wrote:
> On 5 April 2011 03:16, <mailto:eaeltsin@google.com> wrote:
> 
> > Please, add at least one of (mailto:khim@chromium.org, pasko, eaeltsin) to
all
> > gnu
> > toolchain code reviews!
> >
> 
> Sure, this is why I CC'd you. :-)

Thanks a lot for this! My request was for future reviews as well :-)

> 
> 
> > At a first glance newly introduced option looks like duplication of
> > -mno-tls-direct-seg-refs (TARGET_TLS_DIRECT_SEG_REFS) for i386. Please
> > provide
> > some details on the difference (if any :-)).
> >
> 
> No, -mno-tls-direct-seg-refs tells gcc to only use %gs:0 and not to use
> %gs:N where N < 0 (TLS variables are accessed via negative offsets).  In
> fact we already implicitly use -mno-tls-direct-seg-refs on NaCl x86-32
> because NaCl is not able to set up %gs such that negative offsets work.

Yes, my fault.

> 
> The purpose of the new option is to tell gcc not to use %gs at all.

Still I don't understand why the new option is needed, as the rest of this stuff
makes changes for nacl unconditionally and explicitly.

I think just removing "TARGET_64BIT &&" from i386.c:10115 is enough.

If we have time to upstream our gcc changes, most of them will be revised. Thus,
at the moment I'd prefer to introduce as few new things as possible.

[eaeltsin, 2011-04-05 15:42:04]

Or I didn't get that you need both options (gs and call) for x86-32?

On 2011/04/05 15:37:00, Evgeny Eltsin wrote:
> On 2011/04/05 15:12:20, Mark Seaborn wrote:
> > On 5 April 2011 03:16, <mailto:eaeltsin@google.com> wrote:
> > 
> > > Please, add at least one of (mailto:khim@chromium.org, pasko, eaeltsin) to
> all
> > > gnu
> > > toolchain code reviews!
> > >
> > 
> > Sure, this is why I CC'd you. :-)
> 
> Thanks a lot for this! My request was for future reviews as well :-)
> 
> > 
> > 
> > > At a first glance newly introduced option looks like duplication of
> > > -mno-tls-direct-seg-refs (TARGET_TLS_DIRECT_SEG_REFS) for i386. Please
> > > provide
> > > some details on the difference (if any :-)).
> > >
> > 
> > No, -mno-tls-direct-seg-refs tells gcc to only use %gs:0 and not to use
> > %gs:N where N < 0 (TLS variables are accessed via negative offsets).  In
> > fact we already implicitly use -mno-tls-direct-seg-refs on NaCl x86-32
> > because NaCl is not able to set up %gs such that negative offsets work.
> 
> Yes, my fault.
> 
> > 
> > The purpose of the new option is to tell gcc not to use %gs at all.
> 
> Still I don't understand why the new option is needed, as the rest of this
stuff
> makes changes for nacl unconditionally and explicitly.
> 
> I think just removing "TARGET_64BIT &&" from i386.c:10115 is enough.
> 
> If we have time to upstream our gcc changes, most of them will be revised.
Thus,
> at the moment I'd prefer to introduce as few new things as possible.

[Mark Seaborn, 2011-04-05 16:00:29]

On 5 April 2011 08:37, <eaeltsin@google.com> wrote:

> On 2011/04/05 15:12:20, Mark Seaborn wrote:
>
>> The purpose of the new option is to tell gcc not to use %gs at all.
>>
>
> Still I don't understand why the new option is needed, as the rest of this
> stuff
> makes changes for nacl unconditionally and explicitly.
>

We will have two kinds of untrusted code:
 * User code, supplied by web apps.
 * Code in the integrated runtime library, supplied by the browser.

User code should continue to use %gs, because it is faster.  (Reading %gs is
faster than calling __nacl_read_tp()/tls_get() which we use on x86-64.)  But
code in the integrated runtime cannot rely on the same TLS area as user
code, so we will need to redirect its TLS accesses to use a separate set of
thread-local state.

We don't want to use -mtls-use-call by default because of the performance
cost, but we'll probably build libstdc++ and newlib with -mtls-use-call,
because it will probably be awkward to set up two builds of libstdc++ and
newlib.

Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[eaeltsin, 2011-04-05 17:44:35]

lgtm

I'm not happy with having yet another way of building nacl sources... but I
don't want to block the integrated runtime work.