[MIPS] Untrusted versions of setjmp and longjmp.

pnacl/support/tls_get_addr.S

+/*
+ * Copyright (c) 2012 The Native Client Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#include "nacl_mips_defs.h"
+
+/* ====================================================================== */
+/* Some runtime code for Mips */
+/* Access to tls. */
+/* ====================================================================== */
+    .text
+    .align NACL_BLOCK_SHIFT
+    .global __tls_get_addr
+
+__tls_get_addr:

[Mark Seaborn, 2012/10/03 00:46:33]

This function returns the thread's user thread pointer, right?  That's not what
__tls_get_addr() normally does.  __tls_get_addr(void *x) is normally defined by
ld.so; it takes a GOT slot entry address and returns the address of a TLS
variable.

NaCl currently has __nacl_read_tp() which used to be wrongly named
__tls_get_addr(), but that naming conflicted with dynamic linking so we fixed
it.

You could rename this to __nacl_read_tp(), but it might conflict with our
portable implementation in src/untrusted/nacl/nacl_read_tp.c.  More likely, it
just won't get used.  What is leading you to define this function now?

Since defining this in assembly is just an optimisation, you might consider
omitting this definition for now.  (And it's not an ideal optimisation if you
have to call a function to read the thread pointer.)

[petarj, 2012/10/03 16:50:01]

Correct.
At the time we implemented it, your version was also called __tls_get_addr.
We tend to be consistent with the rest of the code even in errors. :)

I now see that Jan has changed that.
It should be renamed, true.
 
We changed LLVM to generate a call to it, in the same vain ARM calls
__aeabi_read_tp. So we need it like ARM needs aeabi_read_tp.S in the same
directory. Do you disagree?
It seems cheaper than to go through the syscall routine.

[Mark Seaborn, 2012/10/03 20:02:54]

Wow, that's a long time ago!  We renamed the wrong __tls_get_addr() in 2010, I
think.
Yes, I've noticed. :-)  You know, if our ARM or x86 code does stupid things, it
would be better if you sent us fixes rather than copying the stupid things. :-)
First let me give some background.  The current implementation of TLS in PNaCl
does some dubious things.  My current plan is to change PNaCl TLS as described
here:  https://code.google.com/p/nativeclient/issues/detail?id=2837

In PNaCl currently:

 * ARM: The translator is *supposed* to convert TLS variables to r9 accesses. 
This means it *shouldn't* normally generate calls to __aeabi_read_tp(). 
However, we build the IRT with -mtls-use-call so that __aeabi_read_tp() calls
are generated, but for the IRT we replace __aeabi_read_tp() with an
implementation that returns the IRT's thread pointer.

 * x86-64: The translator generates calls to __nacl_read_tp().

There is a discrepancy between ARM and x86-64 in PNaCl:

ARM's __aeabi_read_tp() is linked in by the translator (system code), but
x86-64's __nacl_read_tp() is expected to be provided by user code.

The fact that system-generated code depends on a symbol provided by user code is
a bug which we need to fix.  However, for the time being, MIPS could rely on
__nacl_read_tp() being provided by user code as x86-64 does.
But cheaper still is for the translator to generate code that reads $t8 inline,
rather than generating a function call.

You should also bear in mind that we are planning on changing how we use r9 for
TLS on ARM:
https://code.google.com/p/nativeclient/issues/detail?id=2933

You don't need to do the same for MIPS, but it might make things easier if you
do.

+    move    $v0, $t8
+    addiu   $v0, $v0, 0x7000

[Mark Seaborn, 2012/10/03 00:46:33]

What is 0x7000 for?

[petarj, 2012/10/03 16:50:01]

$t8 points to the start of the TLS data area. The thread pointer is offset by
0x7000. This way more data is accessible with signed 16-bit offsets from tp.
This is according to TLS/NPTL ABI for MIPS.

[Mark Seaborn, 2012/10/03 20:02:54]

Hmm, yes, I found some references to that by searching for "mips
__tls_get_addr".  Do you have a canonical reference for Linux's MIPS TLS ABI?  I
found some docs but it was not clear which was authoritative.

It's not clear to me how this offset of 0x7000 will interact with the thread
pointer munging that is done in src/untrusted/nacl/tls_params.h.

Currently tls_params.h in PNaCl is a huge hack.  User code is expected to know
about the different ARM and x86 TLS layouts.  There are PNaCl LLVM intrinsics to
tell user code which to use.  Currently, MIPS-PNaCl would have to pick either
the ARM-style or x86-style TLS layout -- and it's not clear how the 0x7000
offset fits in with either layout.

However, when I've implemented
https://code.google.com/p/nativeclient/issues/detail?id=2837, these layout hacks
should go away.


In conclusion:

Please read
https://code.google.com/p/nativeclient/issues/detail?id=2837 (PNaCl ABI) and
https://code.google.com/p/nativeclient/issues/detail?id=2933 (ARM ABI)
and let me know if you have any questions.  The two are largely independent,
though.

For now, I think you should be able to remove tls_get_addr.S.  If your MIPS
translator generates calls to __nacl_read_tp(), you can currently rely on user
code to define that symbol.  Does that work for you?  If not, I could give you
the benefit of the doubt and OK this change (with tls_get_addr.S renamed).

[petarj, 2012/10/05 17:26:44]

The best documentation I can point you to is:

http://www.linux-mips.org/wiki/NPTL
It should. I have removed the tls_get_addr.S from the patch.

+    and     $ra, $ra, JUMP_MASK
+    jr      $ra
+    nop
+