This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] s/Linux/.../


(Canada leads US, 3 - 2 in the third and final quarter, er....)
I'm going to trickle these fixes in over the next few hours.

Andrew
2002-02-24  Andrew Cagney  <ac131313@redhat.com>

	* lin-lwp.c, thread-db.c, defs.h, cris-tdep.c: Replace ``Linux''
	with either ``GNU/Linux'' or ``Linux kernel''.

Index: cris-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/cris-tdep.c,v
retrieving revision 1.12
diff -u -r1.12 cris-tdep.c
--- cris-tdep.c	2002/02/05 04:37:21	1.12
+++ cris-tdep.c	2002/02/24 21:46:31
@@ -3625,11 +3625,13 @@
 };
 
 /* Fetch (and possibly build) an appropriate link_map_offsets
-   structure for native Linux/CRIS targets using the struct offsets
-   defined in link.h (but without actual reference to that file).
+   structure for native GNU/Linux CRIS targets using the struct
+   offsets defined in link.h (but without actual reference to that
+   file).
 
-   This makes it possible to access Linux/CRIS shared libraries from a
-   GDB that was not built on an Linux/CRIS host (for cross debugging).
+   This makes it possible to access GNU/Linux CRIS shared libraries
+   from a GDB that was not built on an GNU/Linux CRIS host (for cross
+   debugging).
 
    See gdb/solib-svr4.h for an explanation of these fields.  */
 
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.79
diff -u -r1.79 defs.h
--- defs.h	2002/02/13 18:49:29	1.79
+++ defs.h	2002/02/24 21:46:34
@@ -333,13 +333,13 @@
     TARGET_SIGNAL_CANCEL = 76,
 
     /* Yes, this pains me, too.  But LynxOS didn't have SIG32, and now
-       Linux does, and we can't disturb the numbering, since it's part
-       of the remote protocol.  Note that in some GDB's
+       GNU/Linux does, and we can't disturb the numbering, since it's
+       part of the remote protocol.  Note that in some GDB's
        TARGET_SIGNAL_REALTIME_32 is number 76.  */
     TARGET_SIGNAL_REALTIME_32,
     /* Yet another pain, IRIX 6 has SIG64. */
     TARGET_SIGNAL_REALTIME_64,
-    /* Yet another pain, Linux/MIPS might go up to 128. */
+    /* Yet another pain, GNU/Linux MIPS might go up to 128. */
     TARGET_SIGNAL_REALTIME_65,
     TARGET_SIGNAL_REALTIME_66,
     TARGET_SIGNAL_REALTIME_67,
Index: lin-lwp.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-lwp.c,v
retrieving revision 1.31
diff -u -r1.31 lin-lwp.c
--- lin-lwp.c	2001/11/21 21:56:47	1.31
+++ lin-lwp.c	2002/02/24 21:46:36
@@ -1,4 +1,4 @@
-/* Multi-threaded debugging support for Linux (LWP layer).
+/* Multi-threaded debugging support for GNU/Linux (LWP layer).
    Copyright 2000, 2001 Free Software Foundation, Inc.
 
    This file is part of GDB.
@@ -35,38 +35,38 @@
 static int debug_lin_lwp;
 extern const char *strsignal (int sig);
 
-/* On Linux there are no real LWP's.  The closest thing to LWP's are
-   processes sharing the same VM space.  A multi-threaded process is
-   basically a group of such processes.  However, such a grouping is
-   almost entirely a user-space issue; the kernel doesn't enforce such
-   a grouping at all (this might change in the future).  In general,
-   we'll rely on the threads library (i.e. the LinuxThreads library)
-   to provide such a grouping.
+/* On GNU/Linux there are no real LWP's.  The closest thing to LWP's
+   are processes sharing the same VM space.  A multi-threaded process
+   is basically a group of such processes.  However, such a grouping
+   is almost entirely a user-space issue; the kernel doesn't enforce
+   such a grouping at all (this might change in the future).  In
+   general, we'll rely on the threads library (i.e. the GNU/Linux
+   Threads library) to provide such a grouping.
 
    It is perfectly well possible to write a multi-threaded application
    without the assistance of a threads library, by using the clone
    system call directly.  This module should be able to give some
    rudimentary support for debugging such applications if developers
    specify the CLONE_PTRACE flag in the clone system call, and are
-   using Linux 2.4 or above.
+   using the Linux kernel 2.4 or above.
 
-   Note that there are some peculiarities in Linux that affect this
-   code:
+   Note that there are some peculiarities in GNU/Linux that affect
+   this code:
 
    - In general one should specify the __WCLONE flag to waitpid in
      order to make it report events for any of the cloned processes
      (and leave it out for the initial process).  However, if a cloned
      process has exited the exit status is only reported if the
-     __WCLONE flag is absent.  Linux 2.4 has a __WALL flag, but we
-     cannot use it since GDB must work on older systems too.
+     __WCLONE flag is absent.  Linux kernel 2.4 has a __WALL flag, but
+     we cannot use it since GDB must work on older systems too.
 
    - When a traced, cloned process exits and is waited for by the
      debugger, the kernel reassigns it to the original parent and
-     keeps it around as a "zombie".  Somehow, the LinuxThreads library
-     doesn't notice this, which leads to the "zombie problem": When
-     debugged a multi-threaded process that spawns a lot of threads
-     will run out of processes, even if the threads exit, because the
-     "zombies" stay around.  */
+     keeps it around as a "zombie".  Somehow, the GNU/Linux Threads
+     library doesn't notice this, which leads to the "zombie problem":
+     When debugged a multi-threaded process that spawns a lot of
+     threads will run out of processes, even if the threads exit,
+     because the "zombies" stay around.  */
 
 /* Structure describing a LWP.  */
 struct lwp_info
@@ -293,7 +293,7 @@
 }
 
 
-/* Implementation of the PREPARE_TO_PROCEED hook for the Linux LWP
+/* Implementation of the PREPARE_TO_PROCEED hook for the GNU/Linux LWP
    layer.
 
    Note that this implementation is potentially redundant now that
@@ -1476,7 +1476,7 @@
 
   add_show_from_set (add_set_cmd ("lin-lwp", no_class, var_zinteger,
 				  (char *) &debug_lin_lwp, 
-				  "Set debugging of linux lwp module.\n\
+				  "Set debugging of GNU/Linux lwp module.\n\
 Enables printf debugging output.\n",
 				      &setdebuglist),
 		     &showdebuglist);
@@ -1484,7 +1484,8 @@
 
 
 /* FIXME: kettenis/2000-08-26: The stuff on this page is specific to
-   the LinuxThreads library and therefore doesn't really belong here.  */
+   the GNU/Linux Threads library and therefore doesn't really belong
+   here.  */
 
 /* Read variable NAME in the target and return its value if found.
    Otherwise return zero.  It is assumed that the type of the variable
@@ -1528,10 +1529,11 @@
   sigaddset (set, restart);
   sigaddset (set, cancel);
 
-  /* The LinuxThreads library makes terminating threads send a special
-     "cancel" signal instead of SIGCHLD.  Make sure we catch those (to
-     prevent them from terminating GDB itself, which is likely to be
-     their default action) and treat them the same way as SIGCHLD.  */
+  /* The GNU/Linux Threads library makes terminating threads send a
+     special "cancel" signal instead of SIGCHLD.  Make sure we catch
+     those (to prevent them from terminating GDB itself, which is
+     likely to be their default action) and treat them the same way as
+     SIGCHLD.  */
 
   action.sa_handler = sigchld_handler;
   sigemptyset (&action.sa_mask);
Index: thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/thread-db.c,v
retrieving revision 1.20
diff -u -r1.20 thread-db.c
--- thread-db.c	2002/01/08 01:34:12	1.20
+++ thread-db.c	2002/02/24 21:46:42
@@ -37,7 +37,8 @@
 #define LIBTHREAD_DB_SO "libthread_db.so.1"
 #endif
 
-/* If we're running on Linux, we must explicitly attach to any new threads.  */
+/* If we're running on GNU/Linux, we must explicitly attach to any new
+   threads.  */
 
 /* FIXME: There is certainly some room for improvements:
    - Cache LWP ids.
@@ -576,7 +577,7 @@
   if (ti_p->ti_state == TD_THR_UNKNOWN || ti_p->ti_state == TD_THR_ZOMBIE)
     return;			/* A zombie thread -- do not attach.  */
 
-  /* Under Linux, we have to attach to each and every thread.  */
+  /* Under GNU/Linux, we have to attach to each and every thread.  */
 #ifdef ATTACH_LWP
   ATTACH_LWP (BUILD_LWP (ti_p->ti_lid, GET_PID (ptid)), 0);
 #endif

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]