From: Andrew Cagney Date: Sun, 24 Feb 2002 21:53:02 +0000 (+0000) Subject: * lin-lwp.c, thread-db.c, defs.h, cris-tdep.c: Replace ``Linux'' X-Git-Url: http://drtracing.org/?a=commitdiff_plain;h=8605d56e7a489870c1ac2167046a4f4dad8cc13d;p=deliverable%2Fbinutils-gdb.git * lin-lwp.c, thread-db.c, defs.h, cris-tdep.c: Replace ``Linux'' with either ``GNU/Linux'' or ``Linux kernel''. Fix PR gdb/378. --- diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 330f28b550..0c85032b4a 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +2002-02-24 Andrew Cagney + + * 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 * lin-thread.c: Delete file. diff --git a/gdb/cris-tdep.c b/gdb/cris-tdep.c index 5b49a4f5fe..4662ebaac2 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 cf7b0cec4e..7b1a78be0c 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 9931df56f7..e39e78732b 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 df06f3c8b7..2e7620ec48 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