[patch] Fix TLS access for -static -pthread

[patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Hi,

testcase results may depend on patch:
	[patch] Fix gdbserver qGetTLSAddr for x86_64 -m32
	https://sourceware.org/ml/gdb-patches/2014-04/msg00154.html
	Message-ID: <20140410114901.GA16411@host2.jankratochvil.net>

There is:
 * gdb.threads/staticthreads.exp to test -static -pthread 'info threads'
 * gdb.threads/tls.exp to test TLS access (__thread variables)
but no testcase to test both together - it even does not work.

I have posted:
	TLS variables access for -static -lpthread executables
	https://sourceware.org/ml/libc-help/2014-03/msg00024.html
and the GDB patch below has been confirmed as OK for current glibcs.

Future glibcs may implement more native support for -static -pthread TLS
	https://sourceware.org/bugzilla/show_bug.cgi?id=16828
which will require also some new GDB support.

Still the patch below implements the feature in a fully functional way backward
compatible with current glibcs, it depends on the following glibc source line:
	csu/libc-tls.c
	main_map->l_tls_modid = 1;

No regressions on {x86_64,x86_64-m32}-fedorarawhide-linux-gnu.


Thanks,
Jan

[-- Attachment #2: staticthread.patch --]
[-- Type: text/plain, Size: 10037 bytes --]

gdb/
2014-04-10  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* linux-thread-db.c (struct thread_db_info): Add td_thr_tlsbase_p.
	(try_thread_db_load_1): Initialize it.
	(thread_db_get_thread_local_address): Call it if LM is zero.
	* target.c (target_translate_tls_address): Remove LM_ADDR zero check.
	* target.h (struct target_ops) (to_get_thread_local_address): Add
	load_module_addr comment.

gdb/gdbserver/
2014-04-10  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* gdbserver/thread-db.c (struct thread_db): Add td_thr_tlsbase_p.
	(thread_db_get_tls_address): Call it if LOAD_MODULE is zero.
	(thread_db_load_search, try_thread_db_load_1): Initialize it.

gdb/testsuite/
2014-04-10  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* gdb.threads/staticthreads.c <HAVE_TLS> (tlsvar): New.
	<HAVE_TLS> (thread_function, main): Initialize it.
	* gdb.threads/staticthreads.exp: Try gdb_compile_pthreads for $have_tls.
	Add clean_restart.
	<$have_tls != "">: Check TLSVAR.

diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index ca614a3..4578610 100644
--- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -196,6 +196,9 @@ struct thread_db_info
   td_err_e (*td_thr_tls_get_addr_p) (const td_thrhandle_t *th,
 				     psaddr_t map_address,
 				     size_t offset, psaddr_t *address);
+  td_err_e (*td_thr_tlsbase_p) (const td_thrhandle_t *th,
+				unsigned long int modid,
+				psaddr_t *base);
 };
 
 /* List of known processes using thread_db, and the required
@@ -799,6 +802,7 @@ try_thread_db_load_1 (struct thread_db_info *info)
   info->td_ta_event_getmsg_p = dlsym (info->handle, "td_ta_event_getmsg");
   info->td_thr_event_enable_p = dlsym (info->handle, "td_thr_event_enable");
   info->td_thr_tls_get_addr_p = dlsym (info->handle, "td_thr_tls_get_addr");
+  info->td_thr_tlsbase_p = dlsym (info->handle, "td_thr_tlsbase");
 
   if (thread_db_find_new_threads_silently (inferior_ptid) != 0)
     {
@@ -1811,21 +1815,34 @@ thread_db_get_thread_local_address (struct target_ops *ops,
 
       info = get_thread_db_info (ptid_get_pid (ptid));
 
-      /* glibc doesn't provide the needed interface.  */
-      if (!info->td_thr_tls_get_addr_p)
-	throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
-		     _("No TLS library support"));
-
-      /* Caller should have verified that lm != 0.  */
-      gdb_assert (lm != 0);
-
       /* Finally, get the address of the variable.  */
-      /* Note the cast through uintptr_t: this interface only works if
-	 a target address fits in a psaddr_t, which is a host pointer.
-	 So a 32-bit debugger can not access 64-bit TLS through this.  */
-      err = info->td_thr_tls_get_addr_p (&thread_info->private->th,
-					 (psaddr_t)(uintptr_t) lm,
-					 offset, &address);
+      if (lm != 0)
+	{
+	  /* glibc doesn't provide the needed interface.  */
+	  if (!info->td_thr_tls_get_addr_p)
+	    throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
+			 _("No TLS library support"));
+
+	  /* Note the cast through uintptr_t: this interface only works if
+	     a target address fits in a psaddr_t, which is a host pointer.
+	     So a 32-bit debugger can not access 64-bit TLS through this.  */
+	  err = info->td_thr_tls_get_addr_p (&thread_info->private->th,
+					     (psaddr_t)(uintptr_t) lm,
+					     offset, &address);
+	}
+      else
+	{
+	  /* If glibc doesn't provide the needed interface throw an error
+	     that LM is zero - normally cases it should not be.  */
+	  if (!info->td_thr_tlsbase_p)
+	    throw_error (TLS_LOAD_MODULE_NOT_FOUND_ERROR,
+			 _("TLS load module not found"));
+
+	  /* GNU __libc_setup_tls initializes l_tls_modid as 1.  */
+	  err = info->td_thr_tlsbase_p (&thread_info->private->th,
+					1, &address);
+	  address = (char *) address + offset;
+	}
 
 #ifdef THREAD_DB_HAS_TD_NOTALLOC
       /* The memory hasn't been allocated, yet.  */
diff --git a/gdb/target.c b/gdb/target.c
index 1b48f79..fce646c 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -753,10 +753,6 @@ target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
 	  /* Fetch the load module address for this objfile.  */
 	  lm_addr = gdbarch_fetch_tls_load_module_address (target_gdbarch (),
 	                                                   objfile);
-	  /* If it's 0, throw the appropriate exception.  */
-	  if (lm_addr == 0)
-	    throw_error (TLS_LOAD_MODULE_NOT_FOUND_ERROR,
-			 _("TLS load module not found"));
 
 	  addr = target->to_get_thread_local_address (target, ptid,
 						      lm_addr, offset);
diff --git a/gdb/target.h b/gdb/target.h
index d7c6c3d..1aba9e1 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -605,7 +605,8 @@ struct target_ops
        thread-local storage for the thread PTID and the shared library
        or executable file given by OBJFILE.  If that block of
        thread-local storage hasn't been allocated yet, this function
-       may return an error.  */
+       may return an error.  LOAD_MODULE_ADDR may be zero for statically
+       linked multithreaded inferiors.  */
     CORE_ADDR (*to_get_thread_local_address) (struct target_ops *ops,
 					      ptid_t ptid,
 					      CORE_ADDR load_module_addr,
diff --git a/gdb/gdbserver/thread-db.c b/gdb/gdbserver/thread-db.c
index f63e39e..f2335ab 100644
--- a/gdb/gdbserver/thread-db.c
+++ b/gdb/gdbserver/thread-db.c
@@ -88,6 +88,9 @@ struct thread_db
   td_err_e (*td_thr_tls_get_addr_p) (const td_thrhandle_t *th,
 				     psaddr_t map_address,
 				     size_t offset, psaddr_t *address);
+  td_err_e (*td_thr_tlsbase_p) (const td_thrhandle_t *th,
+				unsigned long int modid,
+				psaddr_t *base);
   const char ** (*td_symbol_list_p) (void);
 };
 
@@ -497,7 +500,10 @@ thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset,
   if (thread_db == NULL || !thread_db->all_symbols_looked_up)
     return TD_ERR;
 
-  if (thread_db->td_thr_tls_get_addr_p == NULL)
+  /* If td_thr_tls_get_addr is missing rather do not expect td_thr_tlsbase
+     could work.  */
+  if (thread_db->td_thr_tls_get_addr_p == NULL
+      || (load_module == 0 && thread_db->td_thr_tlsbase_p == NULL))
     return -1;
 
   lwp = get_thread_lwp (thread);
@@ -508,12 +514,23 @@ thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset,
 
   saved_inferior = current_inferior;
   current_inferior = thread;
-  /* Note the cast through uintptr_t: this interface only works if
-     a target address fits in a psaddr_t, which is a host pointer.
-     So a 32-bit debugger can not access 64-bit TLS through this.  */
-  err = thread_db->td_thr_tls_get_addr_p (&lwp->th,
-					  (psaddr_t) (uintptr_t) load_module,
-					  offset, &addr);
+
+  if (load_module != 0)
+    {
+      /* Note the cast through uintptr_t: this interface only works if
+	 a target address fits in a psaddr_t, which is a host pointer.
+	 So a 32-bit debugger can not access 64-bit TLS through this.  */
+      err = thread_db->td_thr_tls_get_addr_p (&lwp->th,
+					     (psaddr_t) (uintptr_t) load_module,
+					      offset, &addr);
+    }
+  else
+    {
+      /* GNU __libc_setup_tls initializes l_tls_modid as 1.  */
+      err = thread_db->td_thr_tlsbase_p (&lwp->th, 1, &addr);
+      addr = (char *) addr + offset;
+    }
+
   current_inferior = saved_inferior;
   if (err == TD_OK)
     {
@@ -565,6 +582,7 @@ thread_db_load_search (void)
   tdb->td_ta_set_event_p = &td_ta_set_event;
   tdb->td_ta_event_getmsg_p = &td_ta_event_getmsg;
   tdb->td_thr_tls_get_addr_p = &td_thr_tls_get_addr;
+  tdb->td_thr_tlsbase_p = &td_thr_tlsbase;
 
   return 1;
 }
@@ -633,6 +651,7 @@ try_thread_db_load_1 (void *handle)
   CHK (0, tdb->td_ta_set_event_p = dlsym (handle, "td_ta_set_event"));
   CHK (0, tdb->td_ta_event_getmsg_p = dlsym (handle, "td_ta_event_getmsg"));
   CHK (0, tdb->td_thr_tls_get_addr_p = dlsym (handle, "td_thr_tls_get_addr"));
+  CHK (0, tdb->td_thr_tlsbase_p = dlsym (handle, "td_thr_tlsbase"));
 
 #undef CHK
 
diff --git a/gdb/testsuite/gdb.threads/staticthreads.c b/gdb/testsuite/gdb.threads/staticthreads.c
index f98f4f1..93bef56 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.c
+++ b/gdb/testsuite/gdb.threads/staticthreads.c
@@ -28,10 +28,17 @@
 
 sem_t semaphore;
 
+#ifdef HAVE_TLS
+__thread int tlsvar;
+#endif
+
 void *
 thread_function (void *arg)
 {
-  printf ("Thread executing\n");
+#ifdef HAVE_TLS
+  tlsvar = 2;
+#endif
+  printf ("Thread executing\n"); /* tlsvar-is-set */
   while (sem_wait (&semaphore) != 0)
     {
       if (errno != EINTR)
@@ -57,6 +64,9 @@ main (int argc, char **argv)
       return -1;
     }
 
+#ifdef HAVE_TLS
+  tlsvar = 1;
+#endif
 
   /* Create a thread, wait for it to complete.  */
   {
diff --git a/gdb/testsuite/gdb.threads/staticthreads.exp b/gdb/testsuite/gdb.threads/staticthreads.exp
index 80b0ba8..9fa625a 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.exp
+++ b/gdb/testsuite/gdb.threads/staticthreads.exp
@@ -22,11 +22,16 @@
 standard_testfile
 set static_flag "-static"
 
-if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
-	 executable \
-	 [list debug "additional_flags=${static_flag}" \
-	     ]] != "" } {
-    return -1
+foreach have_tls { "-DHAVE_TLS" "" } {
+    if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
+	     executable \
+	     [list debug "additional_flags=${static_flag} ${have_tls}" \
+		 ]] == "" } {
+	break
+    }
+    if { $have_tls == "" } {
+	return -1
+    }
 }
 
 clean_restart ${binfile}
@@ -89,3 +94,18 @@ gdb_test_multiple "quit" "$test" {
         pass "$test"
     }
 }
+clean_restart ${binfile}
+
+
+if { "$have_tls" != "" } {
+    if ![runto_main] {
+	return -1
+    }
+    gdb_breakpoint [gdb_get_line_number "tlsvar-is-set"]
+    gdb_continue_to_breakpoint "tlsvar-is-set" ".* tlsvar-is-set .*"
+    gdb_test "p tlsvar" " = 2" "tlsvar in thread"
+    gdb_test "thread 1" ".*"
+    # Unwind from pthread_join.
+    gdb_test "up 10" " in main .*"
+    gdb_test "p tlsvar" " = 1" "tlsvar in main"
+}

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Thu, 10 Apr 2014 13:52:04 +0200, Jan Kratochvil wrote:
> Future glibcs may implement more native support for -static -pthread TLS
> 	https://sourceware.org/bugzilla/show_bug.cgi?id=16828
> which will require also some new GDB support.

Posted now by Carlos O'Donell:
	[PATCH] Initialize _r_debug for static applications.
	https://sourceware.org/ml/libc-alpha/2014-04/msg00183.html
	Message-ID: <5347321E.2060802@redhat.com>


Jan

Re: [patch] Fix TLS access for -static -pthread

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> I have posted:
Jan> 	TLS variables access for -static -lpthread executables
Jan> 	https://sourceware.org/ml/libc-help/2014-03/msg00024.html
Jan> and the GDB patch below has been confirmed as OK for current glibcs.

Jan> +	  /* GNU __libc_setup_tls initializes l_tls_modid as 1.  */
Jan> +	  err = info->td_thr_tlsbase_p (&thread_info->private->th,
Jan> +					1, &address);

This bit of code (and another like it later on) should have a longer
comment, probably at least including the link above, but also some text
about how this is a hack but why it is ok.

Otherwise this is ok.

Tom

Re: [patch] Fix TLS access for -static -pthread

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> On Thu, 10 Apr 2014 13:52:04 +0200, Jan Kratochvil wrote:
>> Future glibcs may implement more native support for -static -pthread TLS
>> https://sourceware.org/bugzilla/show_bug.cgi?id=16828
>> which will require also some new GDB support.

Jan> Posted now by Carlos O'Donell:
Jan> 	[PATCH] Initialize _r_debug for static applications.
Jan> 	https://sourceware.org/ml/libc-alpha/2014-04/msg00183.html
Jan> 	Message-ID: <5347321E.2060802@redhat.com>

Does this negate the need for the previous patch?
Or merely mean that an additional patch is desirable?

Tom

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Tue, 20 May 2014 17:10:35 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> On Thu, 10 Apr 2014 13:52:04 +0200, Jan Kratochvil wrote:
> >> Future glibcs may implement more native support for -static -pthread TLS
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=16828
> >> which will require also some new GDB support.
> 
> Jan> Posted now by Carlos O'Donell:
> Jan> 	[PATCH] Initialize _r_debug for static applications.
> Jan> 	https://sourceware.org/ml/libc-alpha/2014-04/msg00183.html
> Jan> 	Message-ID: <5347321E.2060802@redhat.com>
> 
> Does this negate the need for the previous patch?

No.

> Or merely mean that an additional patch is desirable?

Yes, filed for GDB such additional patch request as:
	Improve TLS variables glibc compatibility
	https://sourceware.org/bugzilla/show_bug.cgi?id=16954


Jan

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Tue, 20 May 2014 17:10:03 +0200, Tom Tromey wrote:
> This bit of code (and another like it later on) should have a longer
> comment, probably at least including the link above, but also some text
> about how this is a hack but why it is ok.

I have put there:
+      /* This code path handles the case of -static -pthread executables:
+	 https://sourceware.org/ml/libc-help/2014-03/msg00024.html
+	 For older GNU libc r_debug.r_map is NULL.  For GNU libc after
+	 PR libc/16831 due to GDB PR threads/16954 LOAD_MODULE is also NULL.
+	 The constant number 1 depends on GNU __libc_setup_tls
+	 initialization of l_tls_modid to 1.  */


> Otherwise this is ok.

Reposting with the comment update.


Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 10671 bytes --]

gdb/
2014-05-21  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* linux-thread-db.c (struct thread_db_info): Add td_thr_tlsbase_p.
	(try_thread_db_load_1): Initialize it.
	(thread_db_get_thread_local_address): Call it if LM is zero.
	* target.c (target_translate_tls_address): Remove LM_ADDR zero check.
	* target.h (struct target_ops) (to_get_thread_local_address): Add
	load_module_addr comment.

gdb/gdbserver/
2014-05-21  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* gdbserver/thread-db.c (struct thread_db): Add td_thr_tlsbase_p.
	(thread_db_get_tls_address): Call it if LOAD_MODULE is zero.
	(thread_db_load_search, try_thread_db_load_1): Initialize it.

gdb/testsuite/
2014-04-10  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix TLS access for -static -pthread.
	* gdb.threads/staticthreads.c <HAVE_TLS> (tlsvar): New.
	<HAVE_TLS> (thread_function, main): Initialize it.
	* gdb.threads/staticthreads.exp: Try gdb_compile_pthreads for $have_tls.
	Add clean_restart.
	<$have_tls != "">: Check TLSVAR.

diff --git a/gdb/gdbserver/thread-db.c b/gdb/gdbserver/thread-db.c
index ae0d191..3ea0cc3 100644
--- a/gdb/gdbserver/thread-db.c
+++ b/gdb/gdbserver/thread-db.c
@@ -88,6 +88,9 @@ struct thread_db
   td_err_e (*td_thr_tls_get_addr_p) (const td_thrhandle_t *th,
 				     psaddr_t map_address,
 				     size_t offset, psaddr_t *address);
+  td_err_e (*td_thr_tlsbase_p) (const td_thrhandle_t *th,
+				unsigned long int modid,
+				psaddr_t *base);
   const char ** (*td_symbol_list_p) (void);
 };
 
@@ -503,7 +506,10 @@ thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset,
   if (thread_db == NULL || !thread_db->all_symbols_looked_up)
     return TD_ERR;
 
-  if (thread_db->td_thr_tls_get_addr_p == NULL)
+  /* If td_thr_tls_get_addr is missing rather do not expect td_thr_tlsbase
+     could work.  */
+  if (thread_db->td_thr_tls_get_addr_p == NULL
+      || (load_module == 0 && thread_db->td_thr_tlsbase_p == NULL))
     return -1;
 
   lwp = get_thread_lwp (thread);
@@ -514,12 +520,28 @@ thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset,
 
   saved_inferior = current_inferior;
   current_inferior = thread;
-  /* Note the cast through uintptr_t: this interface only works if
-     a target address fits in a psaddr_t, which is a host pointer.
-     So a 32-bit debugger can not access 64-bit TLS through this.  */
-  err = thread_db->td_thr_tls_get_addr_p (&lwp->th,
-					  (psaddr_t) (uintptr_t) load_module,
-					  offset, &addr);
+
+  if (load_module != 0)
+    {
+      /* Note the cast through uintptr_t: this interface only works if
+	 a target address fits in a psaddr_t, which is a host pointer.
+	 So a 32-bit debugger can not access 64-bit TLS through this.  */
+      err = thread_db->td_thr_tls_get_addr_p (&lwp->th,
+					     (psaddr_t) (uintptr_t) load_module,
+					      offset, &addr);
+    }
+  else
+    {
+      /* This code path handles the case of -static -pthread executables:
+	 https://sourceware.org/ml/libc-help/2014-03/msg00024.html
+	 For older GNU libc r_debug.r_map is NULL.  For GNU libc after
+	 PR libc/16831 due to GDB PR threads/16954 LOAD_MODULE is also NULL.
+	 The constant number 1 depends on GNU __libc_setup_tls
+	 initialization of l_tls_modid to 1.  */
+      err = thread_db->td_thr_tlsbase_p (&lwp->th, 1, &addr);
+      addr = (char *) addr + offset;
+    }
+
   current_inferior = saved_inferior;
   if (err == TD_OK)
     {
@@ -571,6 +593,7 @@ thread_db_load_search (void)
   tdb->td_ta_set_event_p = &td_ta_set_event;
   tdb->td_ta_event_getmsg_p = &td_ta_event_getmsg;
   tdb->td_thr_tls_get_addr_p = &td_thr_tls_get_addr;
+  tdb->td_thr_tlsbase_p = &td_thr_tlsbase;
 
   return 1;
 }
@@ -639,6 +662,7 @@ try_thread_db_load_1 (void *handle)
   CHK (0, tdb->td_ta_set_event_p = dlsym (handle, "td_ta_set_event"));
   CHK (0, tdb->td_ta_event_getmsg_p = dlsym (handle, "td_ta_event_getmsg"));
   CHK (0, tdb->td_thr_tls_get_addr_p = dlsym (handle, "td_thr_tls_get_addr"));
+  CHK (0, tdb->td_thr_tlsbase_p = dlsym (handle, "td_thr_tlsbase"));
 
 #undef CHK
 
diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index ca614a3..c0f7b1a 100644
--- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -196,6 +196,9 @@ struct thread_db_info
   td_err_e (*td_thr_tls_get_addr_p) (const td_thrhandle_t *th,
 				     psaddr_t map_address,
 				     size_t offset, psaddr_t *address);
+  td_err_e (*td_thr_tlsbase_p) (const td_thrhandle_t *th,
+				unsigned long int modid,
+				psaddr_t *base);
 };
 
 /* List of known processes using thread_db, and the required
@@ -799,6 +802,7 @@ try_thread_db_load_1 (struct thread_db_info *info)
   info->td_ta_event_getmsg_p = dlsym (info->handle, "td_ta_event_getmsg");
   info->td_thr_event_enable_p = dlsym (info->handle, "td_thr_event_enable");
   info->td_thr_tls_get_addr_p = dlsym (info->handle, "td_thr_tls_get_addr");
+  info->td_thr_tlsbase_p = dlsym (info->handle, "td_thr_tlsbase");
 
   if (thread_db_find_new_threads_silently (inferior_ptid) != 0)
     {
@@ -1811,21 +1815,39 @@ thread_db_get_thread_local_address (struct target_ops *ops,
 
       info = get_thread_db_info (ptid_get_pid (ptid));
 
-      /* glibc doesn't provide the needed interface.  */
-      if (!info->td_thr_tls_get_addr_p)
-	throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
-		     _("No TLS library support"));
-
-      /* Caller should have verified that lm != 0.  */
-      gdb_assert (lm != 0);
-
       /* Finally, get the address of the variable.  */
-      /* Note the cast through uintptr_t: this interface only works if
-	 a target address fits in a psaddr_t, which is a host pointer.
-	 So a 32-bit debugger can not access 64-bit TLS through this.  */
-      err = info->td_thr_tls_get_addr_p (&thread_info->private->th,
-					 (psaddr_t)(uintptr_t) lm,
-					 offset, &address);
+      if (lm != 0)
+	{
+	  /* glibc doesn't provide the needed interface.  */
+	  if (!info->td_thr_tls_get_addr_p)
+	    throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
+			 _("No TLS library support"));
+
+	  /* Note the cast through uintptr_t: this interface only works if
+	     a target address fits in a psaddr_t, which is a host pointer.
+	     So a 32-bit debugger can not access 64-bit TLS through this.  */
+	  err = info->td_thr_tls_get_addr_p (&thread_info->private->th,
+					     (psaddr_t)(uintptr_t) lm,
+					     offset, &address);
+	}
+      else
+	{
+	  /* If glibc doesn't provide the needed interface throw an error
+	     that LM is zero - normally cases it should not be.  */
+	  if (!info->td_thr_tlsbase_p)
+	    throw_error (TLS_LOAD_MODULE_NOT_FOUND_ERROR,
+			 _("TLS load module not found"));
+
+	  /* This code path handles the case of -static -pthread executables:
+	     https://sourceware.org/ml/libc-help/2014-03/msg00024.html
+	     For older GNU libc r_debug.r_map is NULL.  For GNU libc after
+	     PR libc/16831 due to GDB PR threads/16954 LOAD_MODULE is also NULL.
+	     The constant number 1 depends on GNU __libc_setup_tls
+	     initialization of l_tls_modid to 1.  */
+	  err = info->td_thr_tlsbase_p (&thread_info->private->th,
+					1, &address);
+	  address = (char *) address + offset;
+	}
 
 #ifdef THREAD_DB_HAS_TD_NOTALLOC
       /* The memory hasn't been allocated, yet.  */
diff --git a/gdb/target.c b/gdb/target.c
index d08e2ea..71292d3 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -757,10 +757,6 @@ target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
 	  /* Fetch the load module address for this objfile.  */
 	  lm_addr = gdbarch_fetch_tls_load_module_address (target_gdbarch (),
 	                                                   objfile);
-	  /* If it's 0, throw the appropriate exception.  */
-	  if (lm_addr == 0)
-	    throw_error (TLS_LOAD_MODULE_NOT_FOUND_ERROR,
-			 _("TLS load module not found"));
 
 	  addr = target->to_get_thread_local_address (target, ptid,
 						      lm_addr, offset);
diff --git a/gdb/target.h b/gdb/target.h
index 23a7566..9371529 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -605,7 +605,8 @@ struct target_ops
        thread-local storage for the thread PTID and the shared library
        or executable file given by OBJFILE.  If that block of
        thread-local storage hasn't been allocated yet, this function
-       may return an error.  */
+       may return an error.  LOAD_MODULE_ADDR may be zero for statically
+       linked multithreaded inferiors.  */
     CORE_ADDR (*to_get_thread_local_address) (struct target_ops *ops,
 					      ptid_t ptid,
 					      CORE_ADDR load_module_addr,
diff --git a/gdb/testsuite/gdb.threads/staticthreads.c b/gdb/testsuite/gdb.threads/staticthreads.c
index e834d7f..5c8eabe 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.c
+++ b/gdb/testsuite/gdb.threads/staticthreads.c
@@ -28,10 +28,17 @@
 
 sem_t semaphore;
 
+#ifdef HAVE_TLS
+__thread int tlsvar;
+#endif
+
 void *
 thread_function (void *arg)
 {
-  printf ("Thread executing\n");
+#ifdef HAVE_TLS
+  tlsvar = 2;
+#endif
+  printf ("Thread executing\n"); /* tlsvar-is-set */
   while (sem_wait (&semaphore) != 0)
     {
       if (errno != EINTR)
@@ -57,6 +64,9 @@ main (int argc, char **argv)
       return -1;
     }
 
+#ifdef HAVE_TLS
+  tlsvar = 1;
+#endif
 
   /* Create a thread, wait for it to complete.  */
   {
diff --git a/gdb/testsuite/gdb.threads/staticthreads.exp b/gdb/testsuite/gdb.threads/staticthreads.exp
index 80b0ba8..9fa625a 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.exp
+++ b/gdb/testsuite/gdb.threads/staticthreads.exp
@@ -22,11 +22,16 @@
 standard_testfile
 set static_flag "-static"
 
-if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
-	 executable \
-	 [list debug "additional_flags=${static_flag}" \
-	     ]] != "" } {
-    return -1
+foreach have_tls { "-DHAVE_TLS" "" } {
+    if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
+	     executable \
+	     [list debug "additional_flags=${static_flag} ${have_tls}" \
+		 ]] == "" } {
+	break
+    }
+    if { $have_tls == "" } {
+	return -1
+    }
 }
 
 clean_restart ${binfile}
@@ -89,3 +94,18 @@ gdb_test_multiple "quit" "$test" {
         pass "$test"
     }
 }
+clean_restart ${binfile}
+
+
+if { "$have_tls" != "" } {
+    if ![runto_main] {
+	return -1
+    }
+    gdb_breakpoint [gdb_get_line_number "tlsvar-is-set"]
+    gdb_continue_to_breakpoint "tlsvar-is-set" ".* tlsvar-is-set .*"
+    gdb_test "p tlsvar" " = 2" "tlsvar in thread"
+    gdb_test "thread 1" ".*"
+    # Unwind from pthread_join.
+    gdb_test "up 10" " in main .*"
+    gdb_test "p tlsvar" " = 1" "tlsvar in main"
+}

Re: [patch] Fix TLS access for -static -pthread

[Tom Tromey]

Tom> This bit of code (and another like it later on) should have a longer
Tom> comment, probably at least including the link above, but also some text
Tom> about how this is a hack but why it is ok.

Jan> I have put there:
Jan> +      /* This code path handles the case of -static -pthread executables:
Jan> +	 https://sourceware.org/ml/libc-help/2014-03/msg00024.html
Jan> +	 For older GNU libc r_debug.r_map is NULL.  For GNU libc after
Jan> +	 PR libc/16831 due to GDB PR threads/16954 LOAD_MODULE is also NULL.
Jan> +	 The constant number 1 depends on GNU __libc_setup_tls
Jan> +	 initialization of l_tls_modid to 1.  */

Thanks, that looks good.

Tom

[commit] [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Wed, 21 May 2014 16:14:09 +0200, Tom Tromey wrote:
> Jan> I have put there:
> Jan> +      /* This code path handles the case of -static -pthread executables:
> Jan> +	 https://sourceware.org/ml/libc-help/2014-03/msg00024.html
> Jan> +	 For older GNU libc r_debug.r_map is NULL.  For GNU libc after
> Jan> +	 PR libc/16831 due to GDB PR threads/16954 LOAD_MODULE is also NULL.
> Jan> +	 The constant number 1 depends on GNU __libc_setup_tls
> Jan> +	 initialization of l_tls_modid to 1.  */
> 
> Thanks, that looks good.

Checked in:
	5876f5032f60c45c4bd19e7ea7d0c14d0346b93e


Jan

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 04/10/2014 07:52 PM, Jan Kratochvil wrote:
> +if { "$have_tls" != "" } {
> +    if ![runto_main] {
> +	return -1
> +    }
> +    gdb_breakpoint [gdb_get_line_number "tlsvar-is-set"]
> +    gdb_continue_to_breakpoint "tlsvar-is-set" ".* tlsvar-is-set .*"
> +    gdb_test "p tlsvar" " = 2" "tlsvar in thread"
> +    gdb_test "thread 1" ".*"
> +    # Unwind from pthread_join.
> +    gdb_test "up 10" " in main .*"

This is racy.  When child thread hits breakpoint, the main thread may
not go into pthread_join yet and may not be unwind to main.
On target arm-none-linux-gnueabi, I see

thread 1^M
[Switching to thread 1 (Thread 5784)]^M
#0  clone () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:62^M
62              cmp     r0, #0^M
(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
up 10^M
#2  0xbe8ea7e4 in ?? ()^M
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10
p tlsvar^M
$2 = 1^M
(gdb) PASS: gdb.threads/staticthreads.exp: tlsvar in main

This patch is to set another breakpoint at the end of main, so that
main thread will hit it, and we can check the value of tlsvar then.
It is safe and we don't have to worry about whether gdb is able to
unwind from pthread library to main function or not.

Is it good to you? b.t.w, this case is UNSUPPORTED on FC 20, because
staticthreads.c can't be compiled.  I guess this case requires
some recent version of glibc.

-- 
Yao (齐尧)
Subject: [PATCH] Fix the race in gdb.threads/staticthreads.exp

The code in gdb.threads/staticthreads.exp about checking the value of
tlsvar in main thread is racy, because when child thread hits
breakpoint, the main thread may not go into pthread_join yet, and
may not be unwind to main.

This patch is to set another breakpoint at the end of main, so that
main thread will hit it, and we can check the value of tlsvar then.

gdb/testsuite:

2014-06-05  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/staticthreads.c (main): Add one line of comment
	as a marker to set breakpoint.
	* gdb.threads/staticthreads.exp: Don't unwind in main thread.
	Instead, set breakpoint on the marker and continue the main
	thread.
---
 gdb/testsuite/gdb.threads/staticthreads.c   | 2 +-
 gdb/testsuite/gdb.threads/staticthreads.exp | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.threads/staticthreads.c b/gdb/testsuite/gdb.threads/staticthreads.c
index 5c8eabe..a11359c 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.c
+++ b/gdb/testsuite/gdb.threads/staticthreads.c
@@ -76,6 +76,6 @@ main (int argc, char **argv)
     pthread_join (thread, NULL);
   }
 
-  pthread_attr_destroy (&attr);
+  pthread_attr_destroy (&attr); /* tlsvar-is-read */
   return 0;
 }
diff --git a/gdb/testsuite/gdb.threads/staticthreads.exp b/gdb/testsuite/gdb.threads/staticthreads.exp
index 9fa625a..3e23b5b 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.exp
+++ b/gdb/testsuite/gdb.threads/staticthreads.exp
@@ -104,8 +104,9 @@ if { "$have_tls" != "" } {
     gdb_breakpoint [gdb_get_line_number "tlsvar-is-set"]
     gdb_continue_to_breakpoint "tlsvar-is-set" ".* tlsvar-is-set .*"
     gdb_test "p tlsvar" " = 2" "tlsvar in thread"
+
     gdb_test "thread 1" ".*"
-    # Unwind from pthread_join.
-    gdb_test "up 10" " in main .*"
+    gdb_breakpoint ${srcfile}:[gdb_get_line_number "tlsvar-is-read"]
+    gdb_continue_to_breakpoint "tlsvar-is-read" ".* tlsvar-is-read .*"
     gdb_test "p tlsvar" " = 1" "tlsvar in main"
 }
-- 
1.9.0

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Thu, 05 Jun 2014 09:15:05 +0200, Yao Qi wrote:
[...]
> thread 1^M
> [Switching to thread 1 (Thread 5784)]^M
> #0  clone () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:62^M
> 62              cmp     r0, #0^M
> (gdb) PASS: gdb.threads/staticthreads.exp: thread 1
> up 10^M
> #2  0xbe8ea7e4 in ?? ()^M
> (gdb) FAIL: gdb.threads/staticthreads.exp: up 10

This is a bug of unwinding clone() at this PC.  IIRC even x86_64 has this or
similar CFI bug, though.


> This patch is to set another breakpoint at the end of main, so that
> main thread will hit it, and we can check the value of tlsvar then.
> It is safe and we don't have to worry about whether gdb is able to
> unwind from pthread library to main function or not.

I have to warn that it may be a bit weaker test, it never tests both threads
TLS access during the same stop, it tests only the current thread.

But it still tests the patch works so I am fine with it (not an approval).


> Is it good to you? b.t.w, this case is UNSUPPORTED on FC 20, because
> staticthreads.c can't be compiled.  I guess this case requires
> some recent version of glibc.

I do not see any unsupported case on
 * Fedora 20 x86_64 updates-testing disabled with debuginfos
 * Fedora 20 x86_64 updates-testing enabled with debuginfos
 * Fedora 20 x86_64 updates-testing enabled without debuginfos
 * Fedora Rawhide x86_64 with debuginfos
for both nat and gdbserver runs.

Sergio said he saw some problem with mktemp symbol on some Fedora but I do not
have that reproducible so I cannot fix it.


Thanks,
Jan

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 06/05/2014 04:06 PM, Jan Kratochvil wrote:
>> This patch is to set another breakpoint at the end of main, so that
>> > main thread will hit it, and we can check the value of tlsvar then.
>> > It is safe and we don't have to worry about whether gdb is able to
>> > unwind from pthread library to main function or not.
> I have to warn that it may be a bit weaker test, it never tests both threads
> TLS access during the same stop, it tests only the current thread.
> 
> But it still tests the patch works so I am fine with it (not an approval).
> 

The patch below is to keep testing TLS access in one stop, and
work around the bug of unwinding clone.  WDYT?

-- 
Yao (齐尧)

Subject: [PATCH] Fix the race in gdb.threads/staticthreads.exp

The code in gdb.threads/staticthreads.exp about checking the value of
tlsvar in main thread is racy, because when child thread hits
breakpoint, the main thread may not go into pthread_join yet, and
may not be unwind to main.

This patch is to move the line setting breakpoint on after sem_wait,
so that the child thread will hit breakpoint after main thread calls
sem_post.  IOW, when child thread hits breakpoint, the main thread is
in either sem_post or pthread_join.  "up 10" can unwind main thread to
main.

gdb/testsuite:

2014-06-05  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/staticthreads.c (thread_function): Move the line
	setting breakpoint on forward.
	* gdb.threads/staticthreads.exp: Update comments.
---
 gdb/testsuite/gdb.threads/staticthreads.c   | 2 +-
 gdb/testsuite/gdb.threads/staticthreads.exp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.threads/staticthreads.c b/gdb/testsuite/gdb.threads/staticthreads.c
index 5c8eabe..db78063 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.c
+++ b/gdb/testsuite/gdb.threads/staticthreads.c
@@ -38,7 +38,6 @@ thread_function (void *arg)
 #ifdef HAVE_TLS
   tlsvar = 2;
 #endif
-  printf ("Thread executing\n"); /* tlsvar-is-set */
   while (sem_wait (&semaphore) != 0)
     {
       if (errno != EINTR)
@@ -47,6 +46,7 @@ thread_function (void *arg)
 	  return NULL;
 	}
     }
+  printf ("Thread executing\n"); /* tlsvar-is-set */
   return NULL;
 }
 
diff --git a/gdb/testsuite/gdb.threads/staticthreads.exp b/gdb/testsuite/gdb.threads/staticthreads.exp
index 9fa625a..bdc03d4 100644
--- a/gdb/testsuite/gdb.threads/staticthreads.exp
+++ b/gdb/testsuite/gdb.threads/staticthreads.exp
@@ -105,7 +105,7 @@ if { "$have_tls" != "" } {
     gdb_continue_to_breakpoint "tlsvar-is-set" ".* tlsvar-is-set .*"
     gdb_test "p tlsvar" " = 2" "tlsvar in thread"
     gdb_test "thread 1" ".*"
-    # Unwind from pthread_join.
+    # Unwind to main.
     gdb_test "up 10" " in main .*"
     gdb_test "p tlsvar" " = 1" "tlsvar in main"
 }
-- 
1.9.0

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Thu, 05 Jun 2014 11:29:32 +0200, Yao Qi wrote:
> The patch below is to keep testing TLS access in one stop, and
> work around the bug of unwinding clone.  WDYT?

Great idea, I like this one more.


Jan

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 06/05/2014 05:39 PM, Jan Kratochvil wrote:
> On Thu, 05 Jun 2014 11:29:32 +0200, Yao Qi wrote:
>> The patch below is to keep testing TLS access in one stop, and
>> work around the bug of unwinding clone.  WDYT?
> 
> Great idea, I like this one more.
> 

Can I check it in?

-- 
Yao (齐尧)

Re: [patch] Fix TLS access for -static -pthread

[Pedro Alves]

On 06/05/2014 09:06 AM, Jan Kratochvil wrote:
> On Thu, 05 Jun 2014 09:15:05 +0200, Yao Qi wrote:
> [...]
>> thread 1^M
>> [Switching to thread 1 (Thread 5784)]^M
>> #0  clone () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:62^M
>> 62              cmp     r0, #0^M
>> (gdb) PASS: gdb.threads/staticthreads.exp: thread 1
>> up 10^M
>> #2  0xbe8ea7e4 in ?? ()^M
>> (gdb) FAIL: gdb.threads/staticthreads.exp: up 10

It'd be nice if this was reported to glibc upstream.

> This is a bug of unwinding clone() at this PC.  IIRC even x86_64 has this or
> similar CFI bug, though.

I think it's fixed.  It works here on f20:

(gdb) bt
#0  thread_function0 (arg=0x0) at threads.c:63
#1  0x000000373c807f33 in start_thread (arg=0x7ffff7fc6700) at pthread_create.c:309
#2  0x000000373bcf4ded in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

It seems this bug ends up easily happening on new ports:

 https://sourceware.org/ml/libc-ports/2012-05/msg00068.html
 https://sourceware.org/ml/libc-alpha/2014-01/msg00337.html

Sounds like nobody has a test to catch this.  Assuming glibc's
backtrace() makes use of CFI, glibc itself could have one.
But maybe we should be have it too - a GNU/Linux specific,
but arch-independent test that makes sure a backtrace in a thread
always stops at clone.  Likewise for catching bogus frames beyond
'_start' in the main thread (with "set backtrace past-main on").

-- 
Pedro Alves

Re: [patch] Fix TLS access for -static -pthread

[Pedro Alves]

On 06/05/2014 03:18 PM, Yao Qi wrote:
> On 06/05/2014 05:39 PM, Jan Kratochvil wrote:
>> On Thu, 05 Jun 2014 11:29:32 +0200, Yao Qi wrote:
>>> The patch below is to keep testing TLS access in one stop, and
>>> work around the bug of unwinding clone.  WDYT?
>>
>> Great idea, I like this one more.
>>
> 
> Can I check it in?

Sure, thanks.

-- 
Pedro Alves

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 06/05/2014 11:23 PM, Pedro Alves wrote:
>> Can I check it in?
> Sure, thanks.

Patch is pushed in.

-- 
Yao (齐尧)

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 06/05/2014 04:06 PM, Jan Kratochvil wrote:
> I do not see any unsupported case on
>  * Fedora 20 x86_64 updates-testing disabled with debuginfos
>  * Fedora 20 x86_64 updates-testing enabled with debuginfos
>  * Fedora 20 x86_64 updates-testing enabled without debuginfos
>  * Fedora Rawhide x86_64 with debuginfos
> for both nat and gdbserver runs.

My machine is Fedora 20 x86, and staticthreads.c can't be compiled
like this:

Executing on host: gcc
../../../../git/gdb/testsuite/gdb.threads/staticthreads.c  -static
-DHAVE_TLS -g  -lpthread -lm   -o
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads
   (timeout = 300)
spawn -ignore SIGHUP gcc
../../../../git/gdb/testsuite/gdb.threads/staticthreads.c -static
-DHAVE_TLS -g -lpthread -lm -o
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads^M
/usr/bin/ld: cannot find -lpthread^M
/usr/bin/ld: cannot find -lm^M
/usr/bin/ld: cannot find -lc^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
/usr/bin/ld: cannot find -lpthread^M
/usr/bin/ld: cannot find -lm^M
/usr/bin/ld: cannot find -lc^M
collect2: error: ld returned 1 exit status^M

Executing on host: gcc
../../../../git/gdb/testsuite/gdb.threads/staticthreads.c  -static
-DHAVE_TLS -g  -lm   -o
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads
   (timeout = 300)
spawn -ignore SIGHUP gcc
../../../../git/gdb/testsuite/gdb.threads/staticthreads.c -static
-DHAVE_TLS -g -lm -o
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads^M
/usr/bin/ld: cannot find -lm^M
/usr/bin/ld: cannot find -lc^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
/usr/bin/ld: cannot find -lm^M
/usr/bin/ld: cannot find -lc^M
collect2: error: ld returned 1 exit status

My glibc version is 2.18 12.fc20 and gcc version is 4.8.2 7.fc20.

-- 
Yao (齐尧)

Re: [patch] Fix TLS access for -static -pthread

[Sergio Durigan Junior]

On Thursday, June 05 2014, Jan Kratochvil wrote:

>> Is it good to you? b.t.w, this case is UNSUPPORTED on FC 20, because
>> staticthreads.c can't be compiled.  I guess this case requires
>> some recent version of glibc.
>
> I do not see any unsupported case on
>  * Fedora 20 x86_64 updates-testing disabled with debuginfos
>  * Fedora 20 x86_64 updates-testing enabled with debuginfos
>  * Fedora 20 x86_64 updates-testing enabled without debuginfos
>  * Fedora Rawhide x86_64 with debuginfos
> for both nat and gdbserver runs.
>
> Sergio said he saw some problem with mktemp symbol on some Fedora but I do not
> have that reproducible so I cannot fix it.

I saw this:

  Executing on host: gcc ../../../gdb/testsuite/gdb.threads/staticthreads.c  -static -DHAVE_TLS -g  -lpthread -lm   -o /patch/to/gdb/testsuite/gdb.threads/staticthreads    (timeout = 300)
  spawn -ignore SIGHUP gcc ../../../gdb/testsuite/gdb.threads/staticthreads.c -static -DHAVE_TLS -g -lpthread -lm -o /patch/to/gdb/testsuite/gdb.threads/staticthreads^M
  /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): In function `sem_open':^M
  (.text+0x774d): warning: the use of `mktemp' is dangerous, better use `mkstemp'^M
  output is:
  /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): In function `sem_open':^M
  (.text+0x774d): warning: the use of `mktemp' is dangerous, better use `mkstemp'^M

This is on RHEL-6.5, with gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4).

I had to do a small workaround in gdb_compile_pthreads (from
testsuite/lib/gdb.exp) in order to make the compilation succeed.

-- 
Sergio
GPG key ID: 65FC5E36
Please send encrypted e-mail if possible
http://blog.sergiodj.net/

Re: [patch] Fix TLS access for -static -pthread

[Yao Qi]

On 06/06/2014 10:34 AM, Yao Qi wrote:
> My machine is Fedora 20 x86, and staticthreads.c can't be compiled
> like this:
> 
> Executing on host: gcc
> ../../../../git/gdb/testsuite/gdb.threads/staticthreads.c  -static
> -DHAVE_TLS -g  -lpthread -lm   -o
> /home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads
>    (timeout = 300)
> spawn -ignore SIGHUP gcc
> ../../../../git/gdb/testsuite/gdb.threads/staticthreads.c -static
> -DHAVE_TLS -g -lpthread -lm -o
> /home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads^M
> /usr/bin/ld: cannot find -lpthread^M
> /usr/bin/ld: cannot find -lm^M
> /usr/bin/ld: cannot find -lc^M
> collect2: error: ld returned 1 exit status^M
> compiler exited with status 1
> output is:
> /usr/bin/ld: cannot find -lpthread^M
> /usr/bin/ld: cannot find -lm^M
> /usr/bin/ld: cannot find -lc^M
> collect2: error: ld returned 1 exit status^M

Installed glibc-static on my machine, then it is compiled successfully.

-- 
Yao (齐尧)

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Fri, 06 Jun 2014 08:14:28 +0200, Yao Qi wrote:
> On 06/06/2014 10:34 AM, Yao Qi wrote:
> > My machine is Fedora 20 x86, and staticthreads.c can't be compiled
> > like this:
> > 
> > Executing on host: gcc
> > ../../../../git/gdb/testsuite/gdb.threads/staticthreads.c  -static
> > -DHAVE_TLS -g  -lpthread -lm   -o
> > /home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads
> >    (timeout = 300)
> > spawn -ignore SIGHUP gcc
> > ../../../../git/gdb/testsuite/gdb.threads/staticthreads.c -static
> > -DHAVE_TLS -g -lpthread -lm -o
> > /home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.threads/staticthreads^M
> > /usr/bin/ld: cannot find -lpthread^M
> > /usr/bin/ld: cannot find -lm^M
> > /usr/bin/ld: cannot find -lc^M
> > collect2: error: ld returned 1 exit status^M
> > compiler exited with status 1
> > output is:
> > /usr/bin/ld: cannot find -lpthread^M
> > /usr/bin/ld: cannot find -lm^M
> > /usr/bin/ld: cannot find -lc^M
> > collect2: error: ld returned 1 exit status^M
> 
> Installed glibc-static on my machine, then it is compiled successfully.

Therefore considering the current FSF GDB state as correct.


Jan

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Fri, 06 Jun 2014 07:34:17 +0200, Sergio Durigan Junior wrote:
> On Thursday, June 05 2014, Jan Kratochvil wrote:
> > Sergio said he saw some problem with mktemp symbol on some Fedora but I do not
> > have that reproducible so I cannot fix it.
> 
> I saw this:
> 
>   Executing on host: gcc ../../../gdb/testsuite/gdb.threads/staticthreads.c  -static -DHAVE_TLS -g  -lpthread -lm   -o /patch/to/gdb/testsuite/gdb.threads/staticthreads    (timeout = 300)
>   spawn -ignore SIGHUP gcc ../../../gdb/testsuite/gdb.threads/staticthreads.c -static -DHAVE_TLS -g -lpthread -lm -o /patch/to/gdb/testsuite/gdb.threads/staticthreads^M
>   /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): In function `sem_open':^M
>   (.text+0x774d): warning: the use of `mktemp' is dangerous, better use `mkstemp'^M
>   output is:
>   /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): In function `sem_open':^M
>   (.text+0x774d): warning: the use of `mktemp' is dangerous, better use `mkstemp'^M
> 
> This is on RHEL-6.5, with gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4).
> 
> I had to do a small workaround in gdb_compile_pthreads (from
> testsuite/lib/gdb.exp) in order to make the compilation succeed.

OK, that may be nice to also submit upstream - but according to the Yao's mail
	Message-ID: <53915C44.3010904@codesourcery.com>
it is unrelated to the problem being discussed in this thread.  Sorry for my
wrong expectation.


Jan

Re: [patch] Fix TLS access for -static -pthread

[Jan Kratochvil]

On Thu, 05 Jun 2014 17:17:41 +0200, Pedro Alves wrote:
> On 06/05/2014 09:06 AM, Jan Kratochvil wrote:
> > On Thu, 05 Jun 2014 09:15:05 +0200, Yao Qi wrote:
> > [...]
> >> thread 1^M
> >> [Switching to thread 1 (Thread 5784)]^M
> >> #0  clone () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:62^M
> >> 62              cmp     r0, #0^M
> >> (gdb) PASS: gdb.threads/staticthreads.exp: thread 1
> >> up 10^M
> >> #2  0xbe8ea7e4 in ?? ()^M
> >> (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
> 
> It'd be nice if this was reported to glibc upstream.

I agree and it is unrelated to the unspecific x86_64 issue I mentioned.


> > This is a bug of unwinding clone() at this PC.  IIRC even x86_64 has this or
> > similar CFI bug, though.
> 
> I think it's fixed.  It works here on f20:

I agree the issue I could not remember much is a different one, I have filed
it now as:
	[x86_64] conditional cfi_undefined missing right after clone()
	https://sourceware.org/bugzilla/show_bug.cgi?id=17033
But it is really unrelated to this mail thread.


Jan