libgo patch committed: Reload m and g if necessary

[Ian Lance Taylor]

PR 50654 points out that many Go tests fail on systems that use emutls.
This turns out to be a subtle issue involving the use of setcontext and
getcontext.  When a particular invocation is moved to run on a different
thread via getcontext and setcontext, it must reload the thread-local
variables m and g.  This happens naturally, because the function call
makes gcc think that they might have changed (as indeed they might
have).  However, gcc knows that the address of the thread-local
variables can not change.  Or at least it thinks it does; if setcontext
causes the function to start running on a different thread, then the
address actually does change.  This means that gcc may cache the address
on the stack in some cases where it must not.

The same issue arises for ordinary TLS, of course, and I have already
fixed most cases.  However, I missed one case.  That case was working
for ordinary TLS because the function refers to both m and g, and gcc
compiles the code such that it holds a pointer to the thread-specific
area and references m and g off that pointer.  This happens to work even
if the function starts running on a different thread.  However, it does
not work when using emultls, for which gcc uses a different compilation
strategy.

This patch fixes the problem.  Bootstrapped and ran Go testsuite on
x86_64-unknonw-linux-gnu, with both regular TLS and emutls.  Committed
to mainline.

Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-diff
Size: 1848 bytes
Desc: patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120214/af6ac69d/attachment.bin>