[obish/6.2] GNU/Linux usage

[obish/6.2] GNU/Linux usage

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 43 bytes --]

FYI,

I've committed the attached.

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 4333 bytes --]

2004-07-17  Andrew Cagney  <cagney@gnu.org>

	* ppc-linux-tdep.c (ppc_linux_init_abi): Add [sic] to Linux.
	* ppc-linux-nat.c: Use "Linux kernel".
	* hppa-linux-tdep.c: Use GNU/Linux.
	* hppa-linux-nat.c: Use GNU/Linux.
	* dwarfread.c: Add [sic] to use of Linux.

Index: dwarfread.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarfread.c,v
retrieving revision 1.40
diff -p -u -r1.40 dwarfread.c
--- dwarfread.c	24 Jun 2004 20:42:42 -0000	1.40
+++ dwarfread.c	17 Jul 2004 14:14:35 -0000
@@ -84,7 +84,7 @@
      On 2003-06-09 the gdb list received a report from a user
        with Absoft ProFortran f77 which is dwarf-1.
 
-     Absoft ProFortran Linux Fortran User Guide (no version,
+     Absoft ProFortran Linux[sic] Fortran User Guide (no version,
      but copyright dates are 1991-2001) says that Absoft ProFortran
      supports -gdwarf1 and -gdwarf2.
 
Index: hppa-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-linux-nat.c,v
retrieving revision 1.5
diff -p -u -r1.5 hppa-linux-nat.c
--- hppa-linux-nat.c	17 Jul 2004 13:58:56 -0000	1.5
+++ hppa-linux-nat.c	17 Jul 2004 14:14:35 -0000
@@ -1,4 +1,5 @@
-/* Functions specific to running gdb native on HPPA running Linux.
+/* Functions specific to running GDB native on HPPA running GNU/Linux.
+
    Copyright 2004 Free Software Foundation, Inc.
 
    This file is part of GDB.
Index: hppa-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-linux-tdep.c,v
retrieving revision 1.8
diff -p -u -r1.8 hppa-linux-tdep.c
--- hppa-linux-tdep.c	7 Jun 2004 02:17:29 -0000	1.8
+++ hppa-linux-tdep.c	17 Jul 2004 14:14:35 -0000
@@ -1,4 +1,4 @@
-/* Target-dependent code for Linux running on PA-RISC, for GDB.
+/* Target-dependent code for GNU/Linux running on PA-RISC, for GDB.
 
    Copyright 2004 Free Software Foundation, Inc.
 
@@ -550,7 +550,7 @@ hppa_linux_init_abi (struct gdbarch_info
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
-  /* Linux is always ELF.  */
+  /* GNU/Linux is always ELF.  */
   tdep->is_elf = 1;
 
   tdep->find_global_pointer = hppa_linux_find_global_pointer;
Index: ppc-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-nat.c,v
retrieving revision 1.45
diff -p -u -r1.45 ppc-linux-nat.c
--- ppc-linux-nat.c	7 Jun 2004 23:37:20 -0000	1.45
+++ ppc-linux-nat.c	17 Jul 2004 14:14:37 -0000
@@ -114,8 +114,8 @@ typedef char gdb_vrregset_t[SIZEOF_VRREG
 
 /* On PPC processors that support the the Signal Processing Extension
    (SPE) APU, the general-purpose registers are 64 bits long.
-   However, the ordinary Linux PTRACE_PEEKUSR / PTRACE_POKEUSR /
-   PT_READ_U / PT_WRITE_U ptrace calls only access the lower half of
+   However, the ordinary Linux kernel PTRACE_PEEKUSR / PTRACE_POKEUSR
+   / PT_READ_U / PT_WRITE_U ptrace calls only access the lower half of
    each register, to allow them to behave the same way they do on
    non-SPE systems.  There's a separate pair of calls,
    PTRACE_GETEVRREGS / PTRACE_SETEVRREGS, that read and write the top
Index: ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.63
diff -p -u -r1.63 ppc-linux-tdep.c
--- ppc-linux-tdep.c	13 May 2004 19:36:05 -0000	1.63
+++ ppc-linux-tdep.c	17 Jul 2004 14:14:37 -0000
@@ -1,7 +1,7 @@
 /* Target-dependent code for GDB, the GNU debugger.
 
    Copyright 1986, 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996,
-   1997, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+   1997, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -1070,7 +1070,7 @@ ppc_linux_init_abi (struct gdbarch_info 
          However, as one of the known warts of its ABI, PPC GNU/Linux
          uses eight-byte long doubles.  GCC only recently got 128-bit
          long double support on PPC, so it may be changing soon.  The
-         Linux Standards Base says that programs that use 'long
+         Linux[sic] Standards Base says that programs that use 'long
          double' on PPC GNU/Linux are non-conformant.  */
       set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
 

Re: [obish/6.2] GNU/Linux usage

[Daniel Jacobowitz]

On Sat, Jul 17, 2004 at 10:17:02AM -0400, Andrew Cagney wrote:
> -         Linux Standards Base says that programs that use 'long
> +         Linux[sic] Standards Base says that programs that use 'long
>           double' on PPC GNU/Linux are non-conformant.  */
>        set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);

Er, is that really necessary?  It's a workgroup named "Linux Standards
Base" and even has the trademark for "LSB".  I'd be annoyed if a [sic]
appeared in the middle of my company name, for sure.

-- 
Daniel Jacobowitz

Re: [obish/6.2] GNU/Linux usage

[Andrew Cagney]

> On Sat, Jul 17, 2004 at 10:17:02AM -0400, Andrew Cagney wrote:
> 
>>> -         Linux Standards Base says that programs that use 'long
>>> +         Linux[sic] Standards Base says that programs that use 'long
>>>           double' on PPC GNU/Linux are non-conformant.  */
>>>        set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
> 
> 
> Er, is that really necessary?  It's a workgroup named "Linux Standards
> Base" and even has the trademark for "LSB".  I'd be annoyed if a [sic]
> appeared in the middle of my company name, for sure.

If we're going to have a mechanical audit process then something is 
needed.  Would you prefer:

	[GNU/]Linux

?

Andrew

Re: [obish/6.2] GNU/Linux usage

[Daniel Jacobowitz]

On Mon, Jul 26, 2004 at 02:36:49PM -0400, Andrew Cagney wrote:
> >On Sat, Jul 17, 2004 at 10:17:02AM -0400, Andrew Cagney wrote:
> >
> >>>-         Linux Standards Base says that programs that use 'long
> >>>+         Linux[sic] Standards Base says that programs that use 'long
> >>>          double' on PPC GNU/Linux are non-conformant.  */
> >>>       set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
> >
> >
> >Er, is that really necessary?  It's a workgroup named "Linux Standards
> >Base" and even has the trademark for "LSB".  I'd be annoyed if a [sic]
> >appeared in the middle of my company name, for sure.
> 
> If we're going to have a mechanical audit process then something is 
> needed.  Would you prefer:
> 
> 	[GNU/]Linux
> 
> ?

Or recognize "Linux Standards Base"?  At least it's conveniently all on
one line.  I'd be just as annoyed if a [GNU/] appeared in the middle of
my company name.

-- 
Daniel Jacobowitz

Re: [obish/6.2] GNU/Linux usage

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:

> On Mon, Jul 26, 2004 at 02:36:49PM -0400, Andrew Cagney wrote:
> > >On Sat, Jul 17, 2004 at 10:17:02AM -0400, Andrew Cagney wrote:
> > >
> > >>>-         Linux Standards Base says that programs that use 'long
> > >>>+         Linux[sic] Standards Base says that programs that use 'long
> > >>>          double' on PPC GNU/Linux are non-conformant.  */
> > >>>       set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
> > >
> > >
> > >Er, is that really necessary?  It's a workgroup named "Linux Standards
> > >Base" and even has the trademark for "LSB".  I'd be annoyed if a [sic]
> > >appeared in the middle of my company name, for sure.
> > 
> > If we're going to have a mechanical audit process then something is 
> > needed.  Would you prefer:
> > 
> > 	[GNU/]Linux
> > 
> > ?
> 
> Or recognize "Linux Standards Base"?  At least it's conveniently all on
> one line.  I'd be just as annoyed if a [GNU/] appeared in the middle of
> my company name.

Yeah, I think recognizing Linux Standards Base is the way to go.  It's
a separate name from "Linux" (the kernel) and "GNU/Linux" (the
system).