[RFA/NEWS] Re: PR corefile/8210: Linux core files should use linux-thread-db.c

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 18 August 2010 15:40:22, Pedro Alves wrote:
> On Wednesday 18 August 2010 15:29:28, Thiago Jung Bauermann wrote:
> > This is patch is great. IMHO it deserves a NEWS entry. :-)
> 
> Eh eh, I knew that was comming.  :-)  I'll take care of that a
> bit later.

And here it is.  Okay to apply?

-- 
Pedro Alves

2010-08-26  Pedro Alves  <pedro@codesourcery.com>

	* NEWS: Mention libthread_db debugging with core files.

---
 gdb/NEWS |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS	2010-08-26 14:49:39.000000000 +0100
+++ src/gdb/NEWS	2010-08-26 20:12:52.000000000 +0100
@@ -37,6 +37,29 @@
   expression.  Such a watchpoint is never deleted due to it going out
   of scope.
 
+* GDB now displays pthread_t ids and allows inspecting TLS variables
+  when debugging core dumps on GNU/Linux.
+
+  GDB now activates thread debugging using the libthread_db library
+  when debugging GNU/Linux core dumps, similarly to when debugging
+  live processes.  As a result, when debugging a core dump file, GDB
+  now able to display pthread_t ids of threads.  For example, "info
+  threads" shows the same output as when debugging the process when it
+  was live.  In earlier releases, you'd see something like this:
+
+  (gdb) info threads
+   * 1 LWP 6780  0x00007f0f567be38d main () at main.c:10
+
+  While now you see this:
+
+  (gdb) info threads
+   * 1 Thread 0x7f0f5712a700 (LWP 6780) main () at main.c:10
+
+  When debugging a core dump generated on a machine not the one used
+  to run GDB, you may need to point GDB at the correct libthread_db
+  library with the "set libthread-db-search-path".  See the user
+  manual for more details on this command.
+
 *** Changes in GDB 7.2
 
 * Shared library support for remote targets by default