aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
Diffstat (limited to 'gdb')
-rw-r--r--gdb/ChangeLog6
-rw-r--r--gdb/cris-tdep.c10
-rw-r--r--gdb/defs.h6
-rw-r--r--gdb/lin-lwp.c52
-rw-r--r--gdb/thread-db.c5
5 files changed, 45 insertions, 34 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 330f28b..0c85032 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+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''.
+ Fix PR gdb/378.
+
2002-02-23 Andrew Cagney <ac131313@redhat.com>
* lin-thread.c: Delete file.
diff --git a/gdb/cris-tdep.c b/gdb/cris-tdep.c
index 5b49a4f..4662eba 100644
--- a/gdb/cris-tdep.c
+++ b/gdb/cris-tdep.c
@@ -3625,11 +3625,13 @@ static struct core_fns cris_elf_core_fns =
};
/* 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. */
diff --git a/gdb/defs.h b/gdb/defs.h
index cf7b0ce..7b1a78b 100644
--- a/gdb/defs.h
+++ b/gdb/defs.h
@@ -333,13 +333,13 @@ enum target_signal
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,
diff --git a/gdb/lin-lwp.c b/gdb/lin-lwp.c
index 9931df5..e39e787 100644
--- a/gdb/lin-lwp.c
+++ b/gdb/lin-lwp.c
@@ -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 @@ iterate_over_lwps (int (*callback) (struct lwp_info *, void *), void *data)
}
-/* 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 @@ _initialize_lin_lwp (void)
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 @@ Enables printf debugging output.\n",
/* 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 @@ lin_thread_get_thread_signals (sigset_t *set)
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);
diff --git a/gdb/thread-db.c b/gdb/thread-db.c
index df06f3c..2e7620e 100644
--- a/gdb/thread-db.c
+++ b/gdb/thread-db.c
@@ -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 @@ attach_thread (ptid_t ptid, const td_thrhandle_t *th_p,
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