From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Sun, 27 Oct 2013 19:15:06 +0100
Subject: IRC.
---
community/gsoc/2013/nlightnfotis.mdwn | 15 +++++++++++++++
1 file changed, 15 insertions(+)
(limited to 'community/gsoc/2013')
diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn
index a9176f51..83e97bc7 100644
--- a/community/gsoc/2013/nlightnfotis.mdwn
+++ b/community/gsoc/2013/nlightnfotis.mdwn
@@ -3035,3 +3035,18 @@ But not the [[open_issues/libpthread_dlopen]] issue?
<nlightnfotis> and we wanna prove that go violates this rule right? That
the stack pointer is not pointing at the initial stack
<braunr> yes
+
+
+# IRC, freenode, #hurd, 2013-10-09
+
+ <gnu_srs> braunr: The crash is not in the assembly code, but in the called
+ function from it:
+ <gnu_srs> pthread_sigmask (how=2, set=0xf9cac <server_block_set>,
+ oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29
+ <gnu_srs> 29 struct __pthread *self = _pthread_self ();
+ <gnu_srs> Program received signal SIGSEGV, Segmentation fault.
+ <braunr> gnu_srs: ok so, same problem as in gcc go
+ <braunr> changing the stack pointer prevents libpthread from correctly
+ fetching thread-specific data (including _pthread_self()) correctly
+ <braunr> this will be fixed when threadvards are finally replaced with true
+ tls
--
cgit v1.2.3