This is the mail archive of the
mailing list for the GDB project.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Sun, 24 Feb 2002 16:50:38 -0500
- Subject: [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.
2002-02-24 Andrew Cagney <firstname.lastname@example.org>
* lin-lwp.c, thread-db.c, defs.h, cris-tdep.c: Replace ``Linux''
with either ``GNU/Linux'' or ``Linux kernel''.
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
- 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
See gdb/solib-svr4.h for an explanation of these fields. */
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. */
/* Yet another pain, IRIX 6 has SIG64. */
- /* Yet another pain, Linux/MIPS might go up to 128. */
+ /* Yet another pain, GNU/Linux MIPS might go up to 128. */
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
+ 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. */
@@ -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
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",
@@ -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;
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"
-/* 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. */
ATTACH_LWP (BUILD_LWP (ti_p->ti_lid, GET_PID (ptid)), 0);