* gdb.texinfo (GDB/MI Development and Front Ends):

	Document *thread-created and *thread-exited.

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index afcdb9b..00e4de2 100644 (file)
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,8 @@
+2008-05-03  Vladimir Prus  <vladimir@codesourcery.com>
+
+       * gdb.texinfo (GDB/MI Development and Front Ends):
+       Document *thread-created and *thread-exited.
+
 2008-05-03  Pedro Alves  <pedro@codesourcery.com>
 
        * observer.texi (thread_exit): New.

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 7abac3c..91c9dee 100644 (file)
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -18062,11 +18062,7 @@ responsibility of the front end to work with the new one.
 The best way to avoid unexpected changes in MI that might break your front
 end is to make your project known to @value{GDBN} developers and
 follow development on @email{gdb@@sourceware.org} and
-@email{gdb-patches@@sourceware.org}.  There is also the mailing list
-@email{dmi-discuss@@lists.freestandards.org}, hosted by the Free Standards
-Group, which has the aim of creating a more general MI protocol
-called Debugger Machine Interface (DMI) that will become a standard
-for all debuggers, not just @value{GDBN}.
+@email{gdb-patches@@sourceware.org}.
 @cindex mailing lists
 
 @c %%%%%%%%%%%%%%%%%%%%%%%%%%%% SECTION %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%