GDB ARIndex cleanup

GDB ARIndex cleanup

[Pierre Muller]

  After several commits related to 
Awk Regression Index page
http://sourceware.org/gdb/current/ari/

I finally came down to 2 Critical items left, i.e. :
Things previously eliminated but returned. This should always be empty.

These are :
inline	11	Do not use the inline attribute; since the compiler
generally ignores this, better algorithm selection is needed to improved
performance

GNU/Linux	7	Do not use `Linux', instead use `Linux kernel' or
`GNU/Linux system'; comments should clearly differentiate between the two
(this test assumes that word `Linux' appears on the same line as the word
`GNU' or `kernel'

I wanted to get feedback on these two issues:

1) "inline"
for inline, someone once said that the
rule that we should not use "inline" keyword
is old, and maybe not correct anymore.

  If everyone agrees that this rule should stay,
I will be happy to commit an obvious fix removing
all of them as this seems quite mechanical,
but I wanted to get some feedback first.

2) GNU/Linux issues.

  This is more difficult for me to fix, as
the difference between "Linux kernel" and "GNU/Linux system" 
is still kind of fuzzy...

  Could someone else look into those issues?

3) I also recompiled doschk program 
so that the list of incompatibilities with 
the DOS limitations is generated again...

Eli, there are probably several directories that we could
disregard for this, but I think that 
there are also real issues left.


Pierre Muller
Pascal language support maintainer for GDB



PS: 
Here is a list of Linux detected problems:

lines 39,43p gdb/ppc-linux-tdep.h
int ppc_linux_trap_reg_p (struct gdbarch *gdbarch);

/* Linux target descriptions.  */
extern struct target_desc *tdesc_powerpc_32l;
extern struct target_desc *tdesc_powerpc_altivec32l;

lines 1273,1279p gdb/amd64-tdep.c
    }

  /* The list of issues to contend with here is taken from
     resume_execution in arch/x86/kernel/kprobes.c, Linux 2.6.28.
     Yay for Free Software!  */

  /* Relocate the %rip back to the program's instruction stream,
lines 70,76p gdb/linux-nat.c
the specific pid, and not passing WNOHANG.

When waiting for an event in all threads, waitpid is not quite good. Prior
to
version 2.4, Linux can either wait for event in main thread, or in secondary
threads. (2.4 has the __WALL flag).  So, if we use blocking waitpid, we
might
miss an event.  The solution is to use non-blocking waitpid, together with
sigsuspend.  First, we use non-blocking waitpid to get an event in the main

lines 430,436p gdb/i386-tdep.c
                        paddr_nz (from), paddr_nz (to), insn[0], insn[1]);

  /* The list of issues to contend with here is taken from
     resume_execution in arch/i386/kernel/kprobes.c, Linux 2.6.20.
     Yay for Free Software!  */

  /* Relocate the %eip, if necessary.  */

lines 165,171p gdb/i386-tdep.h
#define I386_SEL_KPL    0x0000  /* Kernel Privilige Level. */

/* The length of the longest i386 instruction (according to
   include/asm-i386/kprobes.h in Linux 2.6.  */
#define I386_MAX_INSN_LEN (16)

/* Functions exported from i386-tdep.c.  */

lines 659,665p gdb/ppc-linux-tdep.c
  return addr;
}

/* Wrappers to handle Linux-only registers.  */

static void
ppc_linux_supply_gregset (const struct regset *regset,

lines 1175,1181p gdb/ppc-linux-tdep.c
  gdbarch_register_osabi (bfd_arch_rs6000, bfd_mach_rs6k, GDB_OSABI_LINUX,
                         ppc_linux_init_abi);

  /* Initialize the Linux target descriptions.  */
  initialize_tdesc_powerpc_32l ();
  initialize_tdesc_powerpc_altivec32l ();
  initialize_tdesc_powerpc_vsx32l ();

Re: GDB ARIndex cleanup

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb@sourceware.org>, "'Eli Zaretskii'" <eliz@gnu.org>
> Date: Thu, 26 Mar 2009 14:09:49 +0100
> 
> 2) GNU/Linux issues.
> 
>   This is more difficult for me to fix, as
> the difference between "Linux kernel" and "GNU/Linux system" 
> is still kind of fuzzy...
> 
>   Could someone else look into those issues?

Can you publish the list of files where this issue arises?  Are the
files you mentioned in this mail the only ones?

> 3) I also recompiled doschk program 
> so that the list of incompatibilities with 
> the DOS limitations is generated again...
> 
> Eli, there are probably several directories that we could
> disregard for this, but I think that 
> there are also real issues left.

There shouldn't be any.  But to see that, you need to prepare a GDB
tarball, then untar it using djunpack.bat as explained in
gdb/config/djgpp/README, and _then_ run doschk on the resulting tree.
That's because the file-name conflicts are supposed to be solved by
remapping in gdb/config/djgpp/fnchange.lst, which djunpack.bat uses.

> Here is a list of Linux detected problems:

They can all stay "Linux", except for this one:

> lines 39,43p gdb/ppc-linux-tdep.h
> int ppc_linux_trap_reg_p (struct gdbarch *gdbarch);
> 
> /* Linux target descriptions.  */
> extern struct target_desc *tdesc_powerpc_32l;
> extern struct target_desc *tdesc_powerpc_altivec32l;

RE: GDB ARIndex cleanup

[Pierre Muller]

Hi Eli,

> -----Message d'origine-----
> De : Eli Zaretskii [mailto:eliz@gnu.org]
> Envoyé : Thursday, March 26, 2009 9:09 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org; gdb@sourceware.org
> Objet : Re: GDB ARIndex cleanup
> 
> > From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> > Cc: <gdb@sourceware.org>, "'Eli Zaretskii'" <eliz@gnu.org>
> > Date: Thu, 26 Mar 2009 14:09:49 +0100
> >
> > 2) GNU/Linux issues.
> >
> >   This is more difficult for me to fix, as
> > the difference between "Linux kernel" and "GNU/Linux system"
> > is still kind of fuzzy...
> >
> >   Could someone else look into those issues?
> 
> Can you publish the list of files where this issue arises?  Are the
> files you mentioned in this mail the only ones?

It was in my email at the bottom.

> > 3) I also recompiled doschk program
> > so that the list of incompatibilities with
> > the DOS limitations is generated again...
> >
> > Eli, there are probably several directories that we could
> > disregard for this, but I think that
> > there are also real issues left.
> 
> There shouldn't be any.  But to see that, you need to prepare a GDB
> tarball, then untar it using djunpack.bat as explained in
> gdb/config/djgpp/README, and _then_ run doschk on the resulting tree.
> That's because the file-name conflicts are supposed to be solved by
> remapping in gdb/config/djgpp/fnchange.lst, which djunpack.bat uses.

  The question is: 
how do you prepare a tarball that contains only the directories required 
by DJGPP?

  The list of problems is available on the web page: 
http://sourceware.org/gdb/current/ari/ari.doschk.bug

Is for instance the gdb/features/rs6000 directory useful for DJGPP?

I would really like to have an empty list there
and put it to the regression list if this changes,
so that we take care of this as we incompatibilities arise.

Pierre Muller
Pascal language support maintainer for GDB

Re: GDB ARIndex cleanup

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb-patches@sourceware.org>, <gdb@sourceware.org>
> Date: Fri, 27 Mar 2009 09:13:19 +0100
> 
> > > 3) I also recompiled doschk program
> > > so that the list of incompatibilities with
> > > the DOS limitations is generated again...
> > >
> > > Eli, there are probably several directories that we could
> > > disregard for this, but I think that
> > > there are also real issues left.
> > 
> > There shouldn't be any.  But to see that, you need to prepare a GDB
> > tarball, then untar it using djunpack.bat as explained in
> > gdb/config/djgpp/README, and _then_ run doschk on the resulting tree.
> > That's because the file-name conflicts are supposed to be solved by
> > remapping in gdb/config/djgpp/fnchange.lst, which djunpack.bat uses.
> 
>   The question is: 
> how do you prepare a tarball that contains only the directories required 
> by DJGPP?

There's no such thing as a tarball with only the directories required
by DJGPP.  You need a normal GDB tarball, like the ones prepared when
GDB is officially released.  djunpack.bat is designed to work with
such a general-purpose tarball.  You should also be able to use the
snapshot tarballs you can find on sourceware.

>   The list of problems is available on the web page: 
> http://sourceware.org/gdb/current/ari/ari.doschk.bug

Thanks, I will take a look.

Re: GDB ARIndex cleanup

[Eli Zaretskii]

> Date: Fri, 27 Mar 2009 11:41:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, gdb@sourceware.org
> 
> >   The list of problems is available on the web page: 
> > http://sourceware.org/gdb/current/ari/ari.doschk.bug
> 
> Thanks, I will take a look.

OK, I fixed almost all of the problems by suitable changes to
config/djgpp/fnchange.lst.  The only ones left are these:

    The following files are not valid DOS file names:
    ./gdb/gnulib/stdint.in.h - too many dots
    ./gdb/gnulib/string.in.h - too many dots
    ./gdb/gnulib/wchar.in.h - too many dots

I cannot simply rename these via fnchange.lst, since these files are
used during the DJGPP build.  Can these files be renamed to something
more DOS-friendly, like *.h-in ?

Likewise with those:

    The following resolve to the same DOS file names:
    GNULIB-C.M4    : ./gdb/gnulib/m4/gnulib-cache.m4
		     ./gdb/gnulib/m4/gnulib-common.m4
		     ./gdb/gnulib/m4/gnulib-comp.m4

Last, but not least: the libdecnumber/ directory and its
subdirectories have numerous file-name clashes:

    The following resolve to the same DOS file names:
    DECCONTE.H     : ./libdecnumber/decContext.h
		     ./libdecnumber/decContextSymbols.h
    DECDOUBL.H     : ./libdecnumber/decDouble.h
		     ./libdecnumber/decDoubleSymbols.h
    DECIMAL1.H     : ./libdecnumber/bid/decimal128.h
		     ./libdecnumber/bid/decimal128Local.h
		     ./libdecnumber/bid/decimal128Symbols.h
    DECIMAL1.H     : ./libdecnumber/dpd/decimal128.h
		     ./libdecnumber/dpd/decimal128Local.h
		     ./libdecnumber/dpd/decimal128Symbols.h
    DECIMAL3.H     : ./libdecnumber/bid/decimal32.h
		     ./libdecnumber/bid/decimal32Symbols.h
    DECIMAL3.H     : ./libdecnumber/dpd/decimal32.h
		     ./libdecnumber/dpd/decimal32Symbols.h
    DECIMAL6.H     : ./libdecnumber/bid/decimal64.h
		     ./libdecnumber/bid/decimal64Symbols.h
    DECIMAL6.H     : ./libdecnumber/dpd/decimal64.h
		     ./libdecnumber/dpd/decimal64Symbols.h
    DECNUMBE.H     : ./libdecnumber/decNumber.h
		     ./libdecnumber/decNumberLocal.h
		     ./libdecnumber/decNumberSymbols.h
    DECPACKE.H     : ./libdecnumber/decPacked.h
		     ./libdecnumber/decPackedSymbols.h
    DECSINGL.H     : ./libdecnumber/decSingle.h
		     ./libdecnumber/decSingleSymbols.h
    HOST-IEE.C     : ./libdecnumber/bid/host-ieee128.c
		     ./libdecnumber/bid/host-ieee32.c
		     ./libdecnumber/bid/host-ieee64.c

Would it be possible to rename some of the files to resolve these
issues?  Again, it is not possible to use the fnchange.lst machinery
here, as these files are used during the DJGPP build.

Re: GDB ARIndex cleanup

[Eli Zaretskii]

> Date: Fri, 27 Mar 2009 17:03:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>
> 
> OK, I fixed almost all of the problems by suitable changes to
> config/djgpp/fnchange.lst.

Oops, forgot to post the patches.  Here:


2009-03-27  Eli Zaretskii  <eliz@gnu.org>

	* djunpack.bat: Use ".." quoting in Sed command, for the sake of
	Windows builds of Sed.


Index: djunpack.bat
===================================================================
RCS file: /cvs/src/src/djunpack.bat,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- djunpack.bat	8 May 2000 15:13:30 -0000	1.2
+++ djunpack.bat	27 Mar 2009 13:37:09 -0000	1.3
@@ -31,7 +31,7 @@
 copy fnchange.tmp junk.tmp > nul
 if not exist junk.tmp GoTo NoDjTar
 del junk.tmp
-sed -e 's,@V@,%GDBVER%,g' < fnchange.tmp > fnchange.lst
+sed -e "s,@V@,%GDBVER%,g" < fnchange.tmp > fnchange.lst
 Rem See the comment above about the reason for using COPY.
 copy fnchange.lst junk.tmp > nul
 if not exist junk.tmp GoTo NoSed


2009-03-27  Eli Zaretskii  <eliz@gnu.org>

	* config/djgpp/fnchange.lst: Update to fix ARI-reported problems.


Index: gdb/config/djgpp/fnchange.lst
===================================================================
RCS file: /cvs/src/src/gdb/config/djgpp/fnchange.lst,v
retrieving revision 1.99
retrieving revision 1.101
diff -u -r1.99 -r1.101
--- gdb/config/djgpp/fnchange.lst	13 Jan 2009 04:14:07 -0000	1.99
+++ gdb/config/djgpp/fnchange.lst	27 Mar 2009 13:59:38 -0000	1.101
@@ -8,16 +8,24 @@
 @V@/bfd/ChangeLog-2004 @V@/bfd/ChangeLog.004
 @V@/bfd/ChangeLog-2005 @V@/bfd/ChangeLog.005
 @V@/bfd/ChangeLog-2006 @V@/bfd/ChangeLog.006
+@V@/bfd/ChangeLog-2007 @V@/bfd/ChangeLog.007
+@V@/bfd/ChangeLog-2008 @V@/bfd/ChangeLog.008
 @V@/bfd/doc/ChangeLog-9103 @V@/bfd/ChangeLog.9103
 @V@/bfd/coff-tic30.c @V@/bfd/cofftic30.c
 @V@/bfd/coff-tic4x.c @V@/bfd/cofftic40.c
 @V@/bfd/coff-tic54x.c @V@/bfd/cofftic54x.c
 @V@/bfd/coff-tic80.c @V@/bfd/cofftic80.c
+@V@/bfd/cpu-cr16.c @V@/bfd/cpucr16.c
+@V@/bfd/cpu-cr16c.c @V@/bfd/cpucr16c.c
 @V@/bfd/cpu-ia64-opc.c @V@/bfd/cpuia64-opc.c
 @V@/bfd/cpu-m68hc11.c @V@/bfd/cm68hc11.c
 @V@/bfd/cpu-m68hc12.c @V@/bfd/cm68hc12.c
-@V@/bfd/efi-app-ia32.c @V@/bfd/efi-ia32-app.c
-@V@/bfd/efi-app-ia64.c @V@/bfd/efi-ia64-app.c
+@V@/bfd/efi-app-ia32.c @V@/bfd/efiia32app.c
+@V@/bfd/efi-app-ia64.c @V@/bfd/efiia64app.c
+@V@/bfd/efi-bsdrv-ia32.c @V@/bfd/efiia32bsdrv.c
+@V@/bfd/efi-bsdrv-ia64.c @V@/bfd/efiia64bsdrv.c
+@V@/bfd/efi-rtdrv-ia32.c @V@/bfd/efiia32rtdrv.c
+@V@/bfd/efi-rtdrv-ia64.c @V@/bfd/efiia64rtdrv.c
 @V@/bfd/elf32-arc.c @V@/bfd/elf32arc.c
 @V@/bfd/elf32-crx.c @V@/bfd/elf32crx.c
 @V@/bfd/elf32-cris.c @V@/bfd/elf32cris.c
@@ -34,13 +42,20 @@
 @V@/bfd/elf32-m68k.c @V@/bfd/em68k.c
 @V@/bfd/elf32-ppc.c @V@/bfd/e32ppc.c
 @V@/bfd/elf32-sh.c @V@/bfd/e32sh.c
+@V@/bfd/elf32-score.c @V@/bfd/e32score.c
 @V@/bfd/elf32-sh64.c @V@/bfd/e32sh64.c
+@V@/bfd/elf32-sh-relocs.c @V@/bfd/e32sh-relocs.c
+@V@/bfd/elf32-sh-relocs.h @V@/bfd/e32sh-relocs.h
 @V@/bfd/elf32-sh-symbian.c @V@/bfd/e32sh-symbian.c
 @V@/bfd/elf32-sh64-com.c @V@/bfd/e32sh64-com.c
+@V@/bfd/elf32-sparc.c @V@/bfd/e32sparc.c
+@V@/bfd/elf32-spu.c @V@/bfd/e32spu.c
 @V@/bfd/elf64-alpha.c @V@/bfd/e64alphf.c
 @V@/bfd/elf64-sh64.c @V@/bfd/e64sh64.c
 @V@/config/inttypes-pri.m4 @V@/config/pri-inttypes.m4
 @V@/config/inttypes_h.m4 @V@/config/uintmax-inttypes.m4
+@V@/config/mt-mips-elfoabi @V@/config/mt-elfoabi-mips
+@V@/config/mt-mips-gnu @V@/config/mt-gnu-mips
 @V@/dejagnu/baseboards/mn10200-cygmon.exp @V@/dejagnu/baseboards/mn10200cygmon.exp
 @V@/dejagnu/baseboards/mn10200-sim.exp @V@/dejagnu/baseboards/mn10200sim.exp
 @V@/dejagnu/baseboards/mn10300-cygmon.exp @V@/dejagnu/baseboards/mn10300cygmon.exp
@@ -105,6 +120,7 @@
 @V@/gdb/config/alpha/alpha-osf2.mh @V@/gdb/config/alpha/alphosf2.mh
 @V@/gdb/config/alpha/alpha-osf3.mh @V@/gdb/config/alpha/alphosf3.mh
 @V@/gdb/config/alpha/tm-alphalinux.h @V@/gdb/config/alpha/tm-alplinux.h
+@V@/gdb/config/i386/nm-cygwin64.h @V@/gdb/config/i386/nm-cyg64.h
 @V@/gdb/config/i386/nm-linux64.h @V@/gdb/config/i386/nm-lx64.h
 @V@/gdb/config/i386/nm-i386sco4.h @V@/gdb/config/i386/nm-sco4.h
 @V@/gdb/config/i386/nm-i386sco5.h @V@/gdb/config/i386/nm-sco5.h
@@ -120,6 +136,72 @@
 @V@/gdb/config/rs6000/tm-rs6000ly.h @V@/gdb/config/rs6000/tm-rs6kly.h
 @V@/gdb/config/sparc/tm-sparclynx.h @V@/gdb/config/sparc/tm-splynx.h
 @V@/gdb/cp-names.c @V@/gdb/cpnames.c
+@V@/gdb/darwin-nat.c @V@/gdb/drw-nat.c
+@V@/gdb/darwin-nat-info.c @V@/gdb/drw-nat-info.c
+@V@/gdb/features/mips64-cp0.xml @V@/gdb/features/mips64-0cp.xml
+@V@/gdb/features/rs6000/power-fpu-isa205.xml @V@/gdb/features/rs6000/power-isa205.xml
+@V@/gdb/features/rs6000/power64-core.xml @V@/gdb/features/rs6000/power64core.xml
+@V@/gdb/features/rs6000/power64-linux.xml @V@/gdb/features/rs6000/power64linux.xml
+@V@/gdb/features/rs6000/powerpc-32.c @V@/gdb/features/rs6000/ppc-32.c
+@V@/gdb/features/rs6000/powerpc-32l.c @V@/gdb/features/rs6000/ppc-32l.c
+@V@/gdb/features/rs6000/powerpc-403.c @V@/gdb/features/rs6000/ppc-403.c
+@V@/gdb/features/rs6000/powerpc-403gc.c @V@/gdb/features/rs6000/ppc-403gc.c
+@V@/gdb/features/rs6000/powerpc-505.c @V@/gdb/features/rs6000/ppc-505.c
+@V@/gdb/features/rs6000/powerpc-601.c @V@/gdb/features/rs6000/ppc-601.c
+@V@/gdb/features/rs6000/powerpc-602.c @V@/gdb/features/rs6000/ppc-602.c
+@V@/gdb/features/rs6000/powerpc-603.c @V@/gdb/features/rs6000/ppc-603.c
+@V@/gdb/features/rs6000/powerpc-604.c @V@/gdb/features/rs6000/ppc-604.c
+@V@/gdb/features/rs6000/powerpc-64.c @V@/gdb/features/rs6000/ppc-64.c
+@V@/gdb/features/rs6000/powerpc-64l.c @V@/gdb/features/rs6000/ppc-64l.c
+@V@/gdb/features/rs6000/powerpc-7400.c @V@/gdb/features/rs6000/ppc-7400.c
+@V@/gdb/features/rs6000/powerpc-750.c @V@/gdb/features/rs6000/ppc-7500.c
+@V@/gdb/features/rs6000/powerpc-860.c @V@/gdb/features/rs6000/ppc-860.c
+@V@/gdb/features/rs6000/powerpc-altivec32.c @V@/gdb/features/rs6000/ppc-a32.c
+@V@/gdb/features/rs6000/powerpc-altivec32l.c @V@/gdb/features/rs6000/ppc-a32l.c
+@V@/gdb/features/rs6000/powerpc-altivec64.c @V@/gdb/features/rs6000/ppc-a64.c
+@V@/gdb/features/rs6000/powerpc-altivec64l.c @V@/gdb/features/rs6000/ppc-a64l.c
+@V@/gdb/features/rs6000/powerpc-e500.c @V@/gdb/features/rs6000/ppc-e5h.c
+@V@/gdb/features/rs6000/powerpc-e500l.c @V@/gdb/features/rs6000/ppc-e5hl.c
+@V@/gdb/features/rs6000/powerpc-isa205-32l.c @V@/gdb/features/rs6000/ppc-is32.c
+@V@/gdb/features/rs6000/powerpc-isa205-64l.c @V@/gdb/features/rs6000/ppc-is64.c
+@V@/gdb/features/rs6000/powerpc-isa205-altivec32l.c @V@/gdb/features/rs6000/ppcia32l.c
+@V@/gdb/features/rs6000/powerpc-isa205-altivec64l.c @V@/gdb/features/rs6000/ppcia64l.c
+@V@/gdb/features/rs6000/powerpc-isa205-vsx32l.c @V@/gdb/features/rs6000/ppciv32l.c
+@V@/gdb/features/rs6000/powerpc-isa205-vsx64l.c @V@/gdb/features/rs6000/ppciv64l.c
+@V@/gdb/features/rs6000/powerpc-vsx32.c @V@/gdb/features/rs6000/ppc-v32.c
+@V@/gdb/features/rs6000/powerpc-vsx32l.c @V@/gdb/features/rs6000/ppc-v32l.c
+@V@/gdb/features/rs6000/powerpc-vsx64.c @V@/gdb/features/rs6000/ppc-v64.c
+@V@/gdb/features/rs6000/powerpc-vsx64l.c @V@/gdb/features/rs6000/ppc-v64l.c
+@V@/gdb/features/rs6000/powerpc-32.xml @V@/gdb/features/rs6000/ppc-32.xml
+@V@/gdb/features/rs6000/powerpc-32l.xml @V@/gdb/features/rs6000/ppc-32l.xml
+@V@/gdb/features/rs6000/powerpc-403.xml @V@/gdb/features/rs6000/ppc-403.xml
+@V@/gdb/features/rs6000/powerpc-403gc.xml @V@/gdb/features/rs6000/ppc-403gc.xml
+@V@/gdb/features/rs6000/powerpc-505.xml @V@/gdb/features/rs6000/ppc-505.xml
+@V@/gdb/features/rs6000/powerpc-601.xml @V@/gdb/features/rs6000/ppc-601.xml
+@V@/gdb/features/rs6000/powerpc-602.xml @V@/gdb/features/rs6000/ppc-602.xml
+@V@/gdb/features/rs6000/powerpc-603.xml @V@/gdb/features/rs6000/ppc-603.xml
+@V@/gdb/features/rs6000/powerpc-604.xml @V@/gdb/features/rs6000/ppc-604.xml
+@V@/gdb/features/rs6000/powerpc-64.xml @V@/gdb/features/rs6000/ppc-64.xml
+@V@/gdb/features/rs6000/powerpc-64l.xml @V@/gdb/features/rs6000/ppc-64l.xml
+@V@/gdb/features/rs6000/powerpc-7400.xml @V@/gdb/features/rs6000/ppc-7400.xml
+@V@/gdb/features/rs6000/powerpc-750.xml @V@/gdb/features/rs6000/ppc-7500.xml
+@V@/gdb/features/rs6000/powerpc-860.xml @V@/gdb/features/rs6000/ppc-860.xml
+@V@/gdb/features/rs6000/powerpc-altivec32.xml @V@/gdb/features/rs6000/ppc-a32.xml
+@V@/gdb/features/rs6000/powerpc-altivec32l.xml @V@/gdb/features/rs6000/ppc-a32l.xml
+@V@/gdb/features/rs6000/powerpc-altivec64.xml @V@/gdb/features/rs6000/ppc-a64.xml
+@V@/gdb/features/rs6000/powerpc-altivec64l.xml @V@/gdb/features/rs6000/ppc-a64l.xml
+@V@/gdb/features/rs6000/powerpc-e500.xml @V@/gdb/features/rs6000/ppc-e5h.xml
+@V@/gdb/features/rs6000/powerpc-e500l.xml @V@/gdb/features/rs6000/ppc-e5hl.xml
+@V@/gdb/features/rs6000/powerpc-isa205-32l.xml @V@/gdb/features/rs6000/ppc-is32.xml
+@V@/gdb/features/rs6000/powerpc-isa205-64l.xml @V@/gdb/features/rs6000/ppc-is64.xml
+@V@/gdb/features/rs6000/powerpc-isa205-altivec32l.xml @V@/gdb/features/rs6000/ppcia32l.xml
+@V@/gdb/features/rs6000/powerpc-isa205-altivec64l.xml @V@/gdb/features/rs6000/ppcia64l.xml
+@V@/gdb/features/rs6000/powerpc-isa205-vsx32l.xml @V@/gdb/features/rs6000/ppciv32l.xml
+@V@/gdb/features/rs6000/powerpc-isa205-vsx64l.xml @V@/gdb/features/rs6000/ppciv64l.xml
+@V@/gdb/features/rs6000/powerpc-vsx32.xml @V@/gdb/features/rs6000/ppc-v32.xml
+@V@/gdb/features/rs6000/powerpc-vsx32l.xml @V@/gdb/features/rs6000/ppc-v32l.xml
+@V@/gdb/features/rs6000/powerpc-vsx64.xml @V@/gdb/features/rs6000/ppc-v64.xml
+@V@/gdb/features/rs6000/powerpc-vsx64l.xml @V@/gdb/features/rs6000/ppc-v64l.xml
 @V@/gdb/f-exp.tab.c @V@/gdb/f-exp_tab.c
 @V@/gdb/gdbserver/linux-cris-low.c @V@/gdb/gdbserver/lx-cris.c
 @V@/gdb/gdbserver/linux-crisv32-low.c @V@/gdb/gdbserver/lx-cris32.c
@@ -141,6 +223,10 @@
 @V@/gdb/gdbtk/plugins/rhabout/rhabout.tcl.in @V@/gdb/gdbtk/plugins/rhabout/rhabout.t-in
 @V@/gdb/hppabsd-nat.c @V@/gdb/hppab-nat.c
 @V@/gdb/hppabsd-tdep.c @V@/gdb/hppab-tdep.c
+@V@/gdb/hppnbsd-nat.c @V@/gdb/hppnb-nat.c
+@V@/gdb/hppnbsd-tdep.c @V@/gdb/hppnb-tdep.c
+@V@/gdb/i386-darwin-nat.c @V@/gdb/i386dw-nat.c
+@V@/gdb/i386-darwin-tdep.c @V@/gdb/i386dw-tdep.c
 @V@/gdb/i386-interix-nat.c @V@/gdb/i386ix-nat.c
 @V@/gdb/i386-interix-tdep.c @V@/gdb/i386ix-tdep.c
 @V@/gdb/i386-linux-tdep.c @V@/gdb/i386lx-tdep.c
@@ -189,9 +275,24 @@
 @V@/gdb/ppcobsd-nat.c @V@/gdb/ppcob-nat.c
 @V@/gdb/ppcobsd-tdep.c @V@/gdb/ppcob-tdep.c
 @V@/gdb/regformats/reg-i386-linux.dat @V@/gdb/regformats/r-i386-lnx.dat
+@V@/gdb/regformats/reg-x86-64-linux.dat @V@/gdb/regformats/r-x8664-linux.dat
+@V@/gdb/regformats/reg-x86-64.dat @V@/gdb/regformats/r-x8664.dat
 @V@/gdb/regformats/reg-s390x.dat @V@/gdb/regformats/r-s390x.dat
 @V@/gdb/regformats/reg-cris.dat @V@/gdb/regformats/r-cris.dat
 @V@/gdb/regformats/reg-crisv32.dat @V@/gdb/regformats/r-crisv32.dat
+@V@/gdb/regformats/rs6000/powerpc-32l.dat @V@/gdb/regformats/rs6000/ppc-32l.dat
+@V@/gdb/regformats/rs6000/powerpc-64l.dat @V@/gdb/regformats/rs6000/ppc-64l.dat
+@V@/gdb/regformats/rs6000/powerpc-altivec32l.dat @V@/gdb/regformats/rs6000/ppc-a32l.dat
+@V@/gdb/regformats/rs6000/powerpc-altivec64l.dat @V@/gdb/regformats/rs6000/ppc-a64l.dat
+@V@/gdb/regformats/rs6000/powerpc-e500l.dat @V@/gdb/regformats/rs6000/ppc-e5hl.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-32l.dat @V@/gdb/regformats/rs6000/ppc-i32l.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-64l.dat @V@/gdb/regformats/rs6000/ppc-i64l.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-altivec32l.dat @V@/gdb/regformats/rs6000/ppcia32l.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-altivec64l.dat @V@/gdb/regformats/rs6000/ppcia64l.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-vsx32l.dat @V@/gdb/regformats/rs6000/ppciv32l.dat
+@V@/gdb/regformats/rs6000/powerpc-isa205-vsx64l.dat @V@/gdb/regformats/rs6000/ppciv64l.dat
+@V@/gdb/regformats/rs6000/powerpc-vsx32l.dat @V@/gdb/regformats/rs6000/ppc-v32l.dat
+@V@/gdb/regformats/rs6000/powerpc-vsx64l.dat @V@/gdb/regformats/rs6000/ppc-v64l.dat
 @V@/gdb/remote-e7000.c @V@/gdb/rmt-e7000.c
 @V@/gdb/remote-est.c @V@/gdb/rmt-est.c
 @V@/gdb/remote-mips.c @V@/gdb/emt-mips.c
@@ -224,15 +325,53 @@
 @V@/gdb/testsuite/gdb.arch/altivec-abi.exp @V@/gdb/testsuite/gdb.arch/av-abi.exp
 @V@/gdb/testsuite/gdb.arch/altivec-regs.c @V@/gdb/testsuite/gdb.arch/av-regs.c
 @V@/gdb/testsuite/gdb.arch/altivec-regs.exp @V@/gdb/testsuite/gdb.arch/av-regs.exp
+@V@/gdb/testsuite/gdb.arch/i386-size-overlap.c @V@/gdb/testsuite/gdb.arch/i386-overlap-size.c
+@V@/gdb/testsuite/gdb.arch/i386-size-overlap.exp @V@/gdb/testsuite/gdb.arch/i386-overlap-size.exp
 @V@/gdb/testsuite/gdb.arch/powerpc-aix-prologue.exp @V@/gdb/testsuite/gdb.arch/ppcaprol.exp
 @V@/gdb/testsuite/gdb.arch/powerpc-aix-prologue.c @V@/gdb/testsuite/gdb.arch/ppcaprol.c
+@V@/gdb/testsuite/gdb.arch/powerpc-d128-regs.c @V@/gdb/testsuite/gdb.arch/ppc-d128-regs.c
+@V@/gdb/testsuite/gdb.arch/powerpc-prologue.c @V@/gdb/testsuite/gdb.arch/ppc-prologue.c
+@V@/gdb/testsuite/gdb.arch/powerpc-d128-regs.exp @V@/gdb/testsuite/gdb.arch/ppc-d128-regs.exp
+@V@/gdb/testsuite/gdb.arch/powerpc-prologue.exp @V@/gdb/testsuite/gdb.arch/ppc-prologue.exp
 @V@/gdb/testsuite/gdb.base/bitfields2.c @V@/gdb/testsuite/gdb.base/bitfiel2.c
 @V@/gdb/testsuite/gdb.base/bitfields2.exp @V@/gdb/testsuite/gdb.base/bitfiel2.exp
 @V@/gdb/testsuite/gdb.base/coremaker2.c @V@/gdb/testsuite/gdb.base/core2maker.c
+@V@/gdb/testsuite/gdb.base/hashline1.exp @V@/gdb/testsuite/gdb.base/hash1line.exp
+@V@/gdb/testsuite/gdb.base/hashline2.exp @V@/gdb/testsuite/gdb.base/hash2line.exp
+@V@/gdb/testsuite/gdb.base/hashline3.exp @V@/gdb/testsuite/gdb.base/hash3line.exp
+@V@/gdb/testsuite/gdb.base/hook-stop-continue.c @V@/gdb/testsuite/gdb.base/hstop-continue.c
+@V@/gdb/testsuite/gdb.base/hook-stop-frame.c @V@/gdb/testsuite/gdb.base/hstop-frame.c
+@V@/gdb/testsuite/gdb.base/hook-stop-continue.exp @V@/gdb/testsuite/gdb.base/hstop-continue.exp
+@V@/gdb/testsuite/gdb.base/hook-stop-frame.exp @V@/gdb/testsuite/gdb.base/hstop-frame.exp
+@V@/gdb/testsuite/gdb.base/return-nodebug1.c @V@/gdb/testsuite/gdb.base/return-1nodebug.c
+@V@/gdb/testsuite/gdb.base/siginfo-addr.c @V@/gdb/testsuite/gdb.base/si-addr.c
+@V@/gdb/testsuite/gdb.base/siginfo-obj.c @V@/gdb/testsuite/gdb.base/si-obj.c
+@V@/gdb/testsuite/gdb.base/siginfo-addr.exp @V@/gdb/testsuite/gdb.base/si-addr.exp
+@V@/gdb/testsuite/gdb.base/siginfo-obj.exp @V@/gdb/testsuite/gdb.base/si-obj.exp
+@V@/gdb/testsuite/gdb.base/solib-disc.c @V@/gdb/testsuite/gdb.base/so-disc.c
+@V@/gdb/testsuite/gdb.base/solib-display-lib.c @V@/gdb/testsuite/gdb.base/so-displib.c
+@V@/gdb/testsuite/gdb.base/solib-display-main.c @V@/gdb/testsuite/gdb.base/so-dispmain.c
+@V@/gdb/testsuite/gdb.base/solib-disc.exp @V@/gdb/testsuite/gdb.base/so-disc.exp
+@V@/gdb/testsuite/gdb.base/solib-display-lib.exp @V@/gdb/testsuite/gdb.base/so-displib.exp
+@V@/gdb/testsuite/gdb.base/solib-display-main.exp @V@/gdb/testsuite/gdb.base/so-dispmain.exp
+@V@/gdb/testsuite/gdb.base/solib-symbol-lib.c @V@/gdb/testsuite/gdb.base/so-symlib.c
+@V@/gdb/testsuite/gdb.base/solib-symbol-main.c @V@/gdb/testsuite/gdb.base/so-symmain.c
+@V@/gdb/testsuite/gdb.base/type-opaque-lib.c @V@/gdb/testsuite/gdb.base/ty-opqlib.c
+@V@/gdb/testsuite/gdb.base/type-opaque-main.c @V@/gdb/testsuite/gdb.base/ty-opqmain.c
+@V@/gdb/testsuite/gdb.base/watchpoint-hw.c @V@/gdb/testsuite/gdb.base/wp-hw.c
+@V@/gdb/testsuite/gdb.base/watchpoint-solib-shr.c @V@/gdb/testsuite/gdb.base/wp-shr-solib.c
+@V@/gdb/testsuite/gdb.base/watchpoint-solib.c @V@/gdb/testsuite/gdb.base/wp-solib.c
+@V@/gdb/testsuite/gdb.base/watchpoint-hw.exp @V@/gdb/testsuite/gdb.base/wp-hw.exp
+@V@/gdb/testsuite/gdb.base/watchpoint-solib.exp @V@/gdb/testsuite/gdb.base/wp-solib.exp
 @V@/gdb/testsuite/gdb.cp/m-static1.cc @V@/gdb/testsuite/gdb.cp/m-stat1.cc
 @V@/gdb/testsuite/gdb.cp/namespace1.cc @V@/gdb/testsuite/gdb.cp/namesp1.cc
+@V@/gdb/testsuite/gdb.cp/mb-inline1.cc @V@/gdb/testsuite/gdb.cp/mb-inln1.cc
+@V@/gdb/testsuite/gdb.cp/mb-inline2.cc @V@/gdb/testsuite/gdb.cp/mb-inln2.cc
 @V@/gdb/testsuite/gdb.dwarf2/dw2-intermix.exp @V@/gdb/testsuite/gdb.dwarf2/dw2-intmix.exp
 @V@/gdb/testsuite/gdb.dwarf2/dw2-intermix.S @V@/gdb/testsuite/gdb.dwarf2/dw2-intmix.S
+@V@/gdb/testsuite/gdb.dwarf2/dw2-ranges.S @V@/gdb/testsuite/gdb.dwarf2/dw2-rng.S
+@V@/gdb/testsuite/gdb.dwarf2/dw2-ranges2.S @V@/gdb/testsuite/gdb.dwarf2/dw2-rng2.S
+@V@/gdb/testsuite/gdb.dwarf2/dw2-ranges3.S @V@/gdb/testsuite/gdb.dwarf2/dw2-rng3.S
 @V@/gdb/testsuite/gdb.gdbtk/ChangeLog @V@/gdb/testsuite/gdb.tk/ChangeLog
 @V@/gdb/testsuite/gdb.gdbtk/Makefile.in @V@/gdb/testsuite/gdb.tk/Makefile.in
 @V@/gdb/testsuite/gdb.gdbtk/browser.exp @V@/gdb/testsuite/gdb.tk/browser.exp
@@ -264,6 +403,7 @@
 @V@/gdb/testsuite/gdb.gdbtk/windows.test @V@/gdb/testsuite/gdb.tk/windows.test
 @V@/gdb/testsuite/gdb.mi/mi-var-cmd.exp @V@/gdb/testsuite/gdb.mi/mi-varcmd.exp
 @V@/gdb/testsuite/gdb.mi/mi-var-child.exp @V@/gdb/testsuite/gdb.mi/mi-varchild.exp
+@V@/gdb/testsuite/gdb.mi/mi-var-child-f.exp @V@/gdb/testsuite/gdb.mi/mi-fvarchild.exp
 @V@/gdb/testsuite/gdb.mi/mi1-var-block.exp @V@/gdb/testsuite/gdb.mi/mi1varblock.exp
 @V@/gdb/testsuite/gdb.mi/mi1-var-child.exp @V@/gdb/testsuite/gdb.mi/mi1varchild.exp
 @V@/gdb/testsuite/gdb.mi/mi1-var-cmd.exp @V@/gdb/testsuite/gdb.mi/mi1varcmd.exp
@@ -278,6 +418,8 @@
 @V@/gdb/hppa-linux-nat.c @V@/gdb/palnxnat.c
 @V@/gdb/hppa-hpux-nat.c @V@/gdb/pahpuxnat.c
 @V@/gdb/hppa-hpux-tdep.c @V@/gdb/pahpuxtdep.c
+@V@/gdb/hppanbsd-nat.c @V@/gdb/panbsd-nat.c
+@V@/gdb/hppanbsd-nat.c @V@/gdb/panbsd-tdep.c
 @V@/gdb/amd64-windows-nat.c @V@/gdb/amd64-wnat.c
 @V@/gdb/amd64-windows-tdep.c @V@/gdb/amd64-wtdep.c
 @V@/gdb/i386-windows-nat.c @V@/gdb/i386-wnat.c
@@ -286,6 +428,8 @@
 @V@/gdb/windows-tdep.c @V@/gdb/win-tdep.c
 @V@/gdb/windows-tdep.h @V@/gdb/win-tdep.h
 @V@/gdb/windows-termcap.c @V@/gdb/win-tcap.c
+@V@/gdb/xtensa-linux-nat.c @V@/gdb/xtlinuxnat.c
+@V@/gdb/xtensa-linux-tdep.c @V@/gdb/xtlinuxtdep.c
 @V@/include/ChangeLog-9103 @V@/include/ChangeLog.9103
 @V@/include/coff/ChangeLog-9103 @V@/include/coff/ChangeLog.9103
 @V@/include/elf/ChangeLog-9103 @V@/include/elf/ChangeLog.9103
@@ -294,6 +438,8 @@
 @V@/include/xtensa-isa.h @V@/include/xt-isa.h
 @V@/intl/intlh.inst.in @V@/intl/intlh_inst.in
 @V@/intl/po2tbl.sed.in @V@/intl/po2tblsed.in
+@V@/intl/config.intl.in @V@/intl/config_intl.in
+@V@/intl/config.h.in @V@/intl/config.h-in
 @V@/itcl/itcl/itclConfig.sh.in @V@/itcl/itcl/itclConfig.sh-in
 @V@/itcl/itcl/unix/pkgIndex.tcl.in @V@/itcl/itcl/unix/pkgIndex.t-in
 @V@/itcl/itk/itkConfig.sh.in @V@/itcl/itk/itkConfig.sh-in
@@ -310,6 +456,9 @@
 @V@/opcodes/ChangeLog-0203 @V@/opcodes/ChangeLog.0203
 @V@/opcodes/ChangeLog-2004 @V@/opcodes/ChangeLog.004
 @V@/opcodes/ChangeLog-2005 @V@/opcodes/ChangeLog.005
+@V@/opcodes/ChangeLog-2006 @V@/opcodes/ChangeLog.006
+@V@/opcodes/ChangeLog-2007 @V@/opcodes/ChangeLog.007
+@V@/opcodes/ChangeLog-2008 @V@/opcodes/ChangeLog.008
 @V@/opcodes/ia64-opc-a.c @V@/opcodes/ia64opca.c
 @V@/opcodes/ia64-opc-b.c @V@/opcodes/ia64opcb.c
 @V@/opcodes/ia64-opc-d.c @V@/opcodes/ia64opcd.c
@@ -338,6 +487,7 @@
 @V@/opcodes/xstormy16-opc.h @V@/opcodes/xst16opc.h
 @V@/readline/config.h.bot @V@/readline/config.h-bot
 @V@/readline/config.h.in @V@/readline/config.h-in
+@V@/readline/examples/rlfe/config.h.in @V@/readline/examples/rlfe/config.h-in
 @V@/sim/frv/profile-fr400.c @V@/sim/frv/fr400-profile.c
 @V@/sim/cris/semcrisv10f-switch.c @V@/sim/cris/scrisv10f.c
 @V@/sim/cris/semcrisv32f-switch.c @V@/sim/cris/scrisv32f.c
@@ -397,6 +547,10 @@
 @V@/sim/testsuite/sim/cris/asm/tjmpsrv32.ms @V@/sim/testsuite/sim/cris/tjmp32.ms
 @V@/sim/testsuite/sim/cris/c/ftruncate1.c @V@/sim/testsuite/sim/cris/ftrunc1.c
 @V@/sim/testsuite/sim/cris/c/ftruncate2.c @V@/sim/testsuite/sim/cris/ftrunc2.c
+@V@/sim/testsuite/sim/cris/c/hellodyn2.c @V@/sim/testsuite/sim/cris/c/hello2dyn.c
+@V@/sim/testsuite/sim/cris/c/hellodyn3.c @V@/sim/testsuite/sim/cris/c/hello3dyn.c
+@V@/sim/testsuite/sim/cris/c/mprotect1.c @V@/sim/testsuite/sim/cris/c/mprot1.c
+@V@/sim/testsuite/sim/cris/c/mprotect2.c @V@/sim/testsuite/sim/cris/c/mprot2.c
 @V@/sim/testsuite/sim/cris/c/readlink1.c @V@/sim/testsuite/sim/cris/rdlink1.c
 @V@/sim/testsuite/sim/cris/c/readlink2.c @V@/sim/testsuite/sim/cris/rdlink2.c
 @V@/sim/testsuite/sim/cris/c/readlink3.c @V@/sim/testsuite/sim/cris/rdlink3.c
@@ -407,11 +561,18 @@
 @V@/sim/testsuite/sim/cris/c/readlink8.c @V@/sim/testsuite/sim/cris/rdlink8.c
 @V@/sim/testsuite/sim/cris/c/readlink9.c @V@/sim/testsuite/sim/cris/rdlink9.c
 @V@/sim/testsuite/sim/cris/c/readlink10.c @V@/sim/testsuite/sim/cris/rdlink10.c
+@V@/sim/testsuite/sim/cris/c/rtsigprocmask1.c @V@/sim/testsuite/sim/cris/c/rtsig1procmask.c
+@V@/sim/testsuite/sim/cris/c/rtsigprocmask2.c @V@/sim/testsuite/sim/cris/c/rtsig2procmask.c
+@V@/sim/testsuite/sim/cris/c/rtsigsuspend1.c @V@/sim/testsuite/sim/cris/c/rtsig1suspend.c
+@V@/sim/testsuite/sim/cris/c/rtsigsuspend2.c @V@/sim/testsuite/sim/cris/c/rtsig2suspend.c
 @V@/sim/testsuite/sim/cris/c/sigreturn1.c @V@/sim/testsuite/sim/cris/sigret1.c
 @V@/sim/testsuite/sim/cris/c/sigreturn2.c @V@/sim/testsuite/sim/cris/sigret2.c
+@V@/sim/testsuite/sim/cris/c/sigreturn3.c @V@/sim/testsuite/sim/cris/sigret3.c
+@V@/sim/testsuite/sim/cris/c/sigreturn4.c @V@/sim/testsuite/sim/cris/sigret4.c
 @V@/sim/testsuite/sim/cris/c/truncate1.c @V@/sim/testsuite/sim/cris/trunc1.c
 @V@/sim/testsuite/sim/cris/c/truncate2.c @V@/sim/testsuite/sim/cris/trunc2.c
 @V@/sim/testsuite/sim/mips/fpu64-ps-sb1.s @V@/sim/testsuite/sim/mips/fpu64ps-sb1.s
+@V@/sim/testsuite/sim/mips/mips32-dsp2.s @V@/sim/testsuite/sim/mips/mips32-2dsp.s
 @V@/sim/testsuite/sim/frv/interrupts/Ipipe-fr400.cgs @V@/sim/testsuite/sim/frv/interrupts/Ip-fr400.cgs
 @V@/sim/testsuite/sim/frv/interrupts/Ipipe-fr500.cgs @V@/sim/testsuite/sim/frv/interrupts/Ip-fr500.cgs
 @V@/sim/testsuite/sim/frv/interrupts/badalign-fr550.cgs @V@/sim/testsuite/sim/frv/interrupts/fr550-badalign.cgs

Re: GDB ARIndex cleanup

[Thiago Jung Bauermann]

El vie, 27-03-2009 a las 17:03 +0300, Eli Zaretskii escribió:
> Last, but not least: the libdecnumber/ directory and its
> subdirectories have numerous file-name clashes:
> 
>     The following resolve to the same DOS file names:
<snip>
> Would it be possible to rename some of the files to resolve these
> issues?  Again, it is not possible to use the fnchange.lst machinery
> here, as these files are used during the DJGPP build.

libdecnumber is an external library which is imported into the GDB and
GCC trees, so I believe you'd have to discuss this with the library's
author.

The GCC folks seem to incorporate fixes directly to their copy (which
then get copied to us), so perhaps they'll consider the renaming without
involving upstream libdecnumber...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: GDB ARIndex cleanup

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: muller@ics.u-strasbg.fr, gdb-patches@sourceware.org,
>         Joel Brobecker <brobecker@adacore.com>
> Date: Thu, 02 Apr 2009 12:11:52 -0300
> 
> El vie, 27-03-2009 a las 17:03 +0300, Eli Zaretskii escribió:
> > Last, but not least: the libdecnumber/ directory and its
> > subdirectories have numerous file-name clashes:
> > 
> >     The following resolve to the same DOS file names:
> <snip>
> > Would it be possible to rename some of the files to resolve these
> > issues?  Again, it is not possible to use the fnchange.lst machinery
> > here, as these files are used during the DJGPP build.
> 
> libdecnumber is an external library which is imported into the GDB and
> GCC trees, so I believe you'd have to discuss this with the library's
> author.
> 
> The GCC folks seem to incorporate fixes directly to their copy (which
> then get copied to us), so perhaps they'll consider the renaming without
> involving upstream libdecnumber...

Like with gnulib (or maybe even more), I don't think I stand a chance
to get positive responses to my request for this, unless GDB supports
it as a whole project.

I guess I'm asking GDB to ask for this on behalf of the DJGPP port.

Re: GDB ARIndex cleanup

[Joel Brobecker]

> I guess I'm asking GDB to ask for this on behalf of the DJGPP port.

No problem on my end.

-- 
Joel

Re: GDB ARIndex cleanup

[Joel Brobecker]

> 1) "inline"
> for inline, someone once said that the rule that we should not use
> "inline" keyword is old, and maybe not correct anymore.
> 
> If everyone agrees that this rule should stay, I will be happy to
> commit an obvious fix removing all of them as this seems quite
> mechanical, but I wanted to get some feedback first.

I don't know much about the effectiveness of using "inline".
I personally tend to avoid it, because I trust the compiler to determine
whether an inline will help or not. So I'm OK either way.

> This is more difficult for me to fix, as
> the difference between "Linux kernel" and "GNU/Linux system" 
> is still kind of fuzzy...

As a first guess, I think a lot of the references will be to the Linux
kernel. GDB interfaces mostly with the kernel.  GNU/Linux would refer
to the larger systems that runs on the Linux kernel.

However, I'm wondering if this rule is really all that helpful
for the GDB project or not. I suspect this comes from a request
from RMS to make sure that this distinction be made in GNU code.
But it might seem a bit awkward when you read it.

> /* Linux target descriptions.  */

I'm actually not 100% sure about this one. I think that target descriptions
can be used to describe other things than register availability and
numbering. So, generally speaking, the above might be ambiguous. But
in practice, the target_desc below are describing registers, so
Linux Kernel. Again, not 100% sure.

>   /* The list of issues to contend with here is taken from
>      resume_execution in arch/x86/kernel/kprobes.c, Linux 2.6.28.
>      Yay for Free Software!  */

Kernel.

> When waiting for an event in all threads, waitpid is not quite good. Prior
> to
> version 2.4, Linux can either wait for event in main thread, or in secondary

Kernel.

> /* The length of the longest i386 instruction (according to
>    include/asm-i386/kprobes.h in Linux 2.6.  */

Kernel (he's talking about the kernel sources)

> /* Wrappers to handle Linux-only registers.  */

Kernel.

>   /* Initialize the Linux target descriptions.  */

Kernel.  Again, sounds pretty awkward to use "Linux Kernel target
descriptions".

-- 
Joel

Re: GDB ARIndex cleanup

[Daniel Jacobowitz]

On Thu, Mar 26, 2009 at 04:09:59PM -0700, Joel Brobecker wrote:
> > 1) "inline"
> > for inline, someone once said that the rule that we should not use
> > "inline" keyword is old, and maybe not correct anymore.
> > 
> > If everyone agrees that this rule should stay, I will be happy to
> > commit an obvious fix removing all of them as this seems quite
> > mechanical, but I wanted to get some feedback first.
> 
> I don't know much about the effectiveness of using "inline".
> I personally tend to avoid it, because I trust the compiler to determine
> whether an inline will help or not. So I'm OK either way.

My two cents: in practice, it's still useful.  I don't think we need a
rule banning it.

-- 
Daniel Jacobowitz
CodeSourcery

RE: GDB ARIndex cleanup

[Pierre Muller]

> -----Message d'origine-----
> De : Joel Brobecker [mailto:brobecker@adacore.com]
> Envoyé : Friday, March 27, 2009 12:10 AM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org; gdb@sourceware.org; 'Eli Zaretskii'
> Objet : Re: GDB ARIndex cleanup
> 
> > 1) "inline"
> > for inline, someone once said that the rule that we should not use
> > "inline" keyword is old, and maybe not correct anymore.
> >
> > If everyone agrees that this rule should stay, I will be happy to
> > commit an obvious fix removing all of them as this seems quite
> > mechanical, but I wanted to get some feedback first.
> 
> I don't know much about the effectiveness of using "inline".
> I personally tend to avoid it, because I trust the compiler to
> determine
> whether an inline will help or not. So I'm OK either way.

  
As Daniel seems to think that is can be useful
(maybe for non GNU compilers?) should
we use some configure set macro like
INLINE
that would be set to nothing for GNU gcc
but could be inline for other compilers?

Configure already checks for the ability of inline,
but it could be modified to discard inline altogether
for gcc, no?


Pierre Muller
Pascal language support maintainer for GDB

Re: GDB ARIndex cleanup

[Joel Brobecker]

> As Daniel seems to think that is can be useful (maybe for non GNU
> compilers?) should we use some configure set macro like INLINE that
> would be set to nothing for GNU gcc but could be inline for other
> compilers?

I personally don't see the benefit.  I propose we leave things as
they are for now and remove the rule about the use of inline.
Daniel?

-- 
Joel

Re: GDB ARIndex cleanup

[Daniel Jacobowitz]

On Fri, Mar 27, 2009 at 09:00:04AM -0700, Joel Brobecker wrote:
> > As Daniel seems to think that is can be useful (maybe for non GNU
> > compilers?) should we use some configure set macro like INLINE that
> > would be set to nothing for GNU gcc but could be inline for other
> > compilers?
> 
> I personally don't see the benefit.  I propose we leave things as
> they are for now and remove the rule about the use of inline.
> Daniel?

Yes, I agree.  The inline keyword is useful for GCC also.

-- 
Daniel Jacobowitz
CodeSourcery

[RFC] GDB ARIndex Linux rule cleanup

[Pierre Muller]

Following the discussion about GNU/Linux regressions in
ARI pages, I send this for comment.

  Joel told us that all those occurrences should be considered
kernel specific.
  I have no opinion directly on the matter, and I only
send this for the ARI to give better results.


Comments welcome,


Pierre Muller
Pascal language support maintainer for GDB




2009-04-15  Pierre Muller  <muller.u-strasbg.fr>

	ARI fix: GNU/Linux rule in comments.
	* amd64-tdep.c (amd64_displaced_step_fixup): Specify Linux kernel.
	* i386-tdep.c (i386_displaced_step_fixup): Idem.
	* i386-tdep.h (I386_MAX_INSN_LEN): Idem.
	* ppc-linux-tdep.c (ppc_linux_supply_gregset): Idem.
	(_initialize_ppc_linux_tdep): Idem.
	* ppc-linux-tdep.h: Idem.
	* linux-nat.c: Idem in starting comments.
	(linux_nat_filter_event): Idem.

Index: amd64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
retrieving revision 1.58
diff -u -p -r1.58 amd64-tdep.c
--- amd64-tdep.c	17 Feb 2009 06:14:16 -0000	1.58
+++ amd64-tdep.c	14 Apr 2009 22:55:47 -0000
@@ -1273,7 +1273,7 @@ amd64_displaced_step_fixup (struct gdbar
     }
 
   /* The list of issues to contend with here is taken from
-     resume_execution in arch/x86/kernel/kprobes.c, Linux 2.6.28.
+     resume_execution in arch/x86/kernel/kprobes.c, Linux kernel 2.6.28.
      Yay for Free Software!  */
 
   /* Relocate the %rip back to the program's instruction stream,
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.269
diff -u -p -r1.269 i386-tdep.c
--- i386-tdep.c	17 Feb 2009 06:14:16 -0000	1.269
+++ i386-tdep.c	14 Apr 2009 22:55:48 -0000
@@ -430,7 +430,7 @@ i386_displaced_step_fixup (struct gdbarc
                         paddr_nz (from), paddr_nz (to), insn[0], insn[1]);
 
   /* The list of issues to contend with here is taken from
-     resume_execution in arch/i386/kernel/kprobes.c, Linux 2.6.20.
+     resume_execution in arch/i386/kernel/kprobes.c, Linux kernel 2.6.20.
      Yay for Free Software!  */
 
   /* Relocate the %eip, if necessary.  */
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.57
diff -u -p -r1.57 i386-tdep.h
--- i386-tdep.h	4 Feb 2009 14:49:41 -0000	1.57
+++ i386-tdep.h	14 Apr 2009 22:55:48 -0000
@@ -165,7 +165,7 @@ extern struct type *i386_sse_type (struc
 #define I386_SEL_KPL	0x0000	/* Kernel Privilige Level. */
 
 /* The length of the longest i386 instruction (according to
-   include/asm-i386/kprobes.h in Linux 2.6.  */
+   include/asm-i386/kprobes.h in Linux kernel 2.6.  */
 #define I386_MAX_INSN_LEN (16)
 
 /* Functions exported from i386-tdep.c.  */
Index: ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.110
diff -u -p -r1.110 ppc-linux-tdep.c
--- ppc-linux-tdep.c	22 Feb 2009 01:02:19 -0000	1.110
+++ ppc-linux-tdep.c	14 Apr 2009 22:55:48 -0000
@@ -659,7 +659,7 @@ ppc64_linux_convert_from_func_ptr_addr (
   return addr;
 }
 
-/* Wrappers to handle Linux-only registers.  */
+/* Wrappers to handle Linux-only kernel registers.  */
 
 static void
 ppc_linux_supply_gregset (const struct regset *regset,
@@ -1175,7 +1175,7 @@ _initialize_ppc_linux_tdep (void)
   gdbarch_register_osabi (bfd_arch_rs6000, bfd_mach_rs6k, GDB_OSABI_LINUX,
                          ppc_linux_init_abi);
 
-  /* Initialize the Linux target descriptions.  */
+  /* Initialize the Linux kernel target descriptions.  */
   initialize_tdesc_powerpc_32l ();
   initialize_tdesc_powerpc_altivec32l ();
   initialize_tdesc_powerpc_vsx32l ();
Index: ppc-linux-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.h,v
retrieving revision 1.4
diff -u -p -r1.4 ppc-linux-tdep.h
--- ppc-linux-tdep.h	3 Jan 2009 05:57:53 -0000	1.4
+++ ppc-linux-tdep.h	14 Apr 2009 22:55:48 -0000
@@ -38,7 +38,7 @@ enum {
 /* Return 1 if PPC_ORIG_R3_REGNUM and PPC_TRAP_REGNUM are usable.  */
 int ppc_linux_trap_reg_p (struct gdbarch *gdbarch);
 
-/* Linux target descriptions.  */
+/* Linux kernel target descriptions.  */
 extern struct target_desc *tdesc_powerpc_32l;
 extern struct target_desc *tdesc_powerpc_altivec32l;
 extern struct target_desc *tdesc_powerpc_vsx32l;
Index: linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.128
diff -u -p -r1.128 linux-nat.c
--- linux-nat.c	1 Apr 2009 19:07:50 -0000	1.128
+++ linux-nat.c	14 Apr 2009 22:55:50 -0000
@@ -70,7 +70,7 @@ When waiting for an event in a specific 
 the specific pid, and not passing WNOHANG.
 
 When waiting for an event in all threads, waitpid is not quite good. Prior
to
-version 2.4, Linux can either wait for event in main thread, or in
secondary
+version 2.4, Linux kernel can either wait for event in main thread, or in
secondary
 threads. (2.4 has the __WALL flag).  So, if we use blocking waitpid, we
might
 miss an event.  The solution is to use non-blocking waitpid, together with
 sigsuspend.  First, we use non-blocking waitpid to get an event in the main

@@ -2625,7 +2625,7 @@ linux_nat_filter_event (int lwpid, int s
     {
       /* If this is the main thread, we must stop all threads and verify
 	 if they are still alive.  This is because in the nptl thread model
-	 on Linux 2.4, there is no signal issued for exiting LWPs
+	 on Linux kernel 2.4, there is no signal issued for exiting LWPs
 	 other than the main thread.  We only get the main thread exit
 	 signal once all child threads have already exited.  If we
 	 stop all the threads and use the stop_wait_callback to check

Re: [RFC] GDB ARIndex Linux rule cleanup

[Mark Kettenis]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Date: Wed, 15 Apr 2009 01:06:30 +0200
> 
> Following the discussion about GNU/Linux regressions in
> ARI pages, I send this for comment.
> 
>   Joel told us that all those occurrences should be considered
> kernel specific.
>   I have no opinion directly on the matter, and I only
> send this for the ARI to give better results.

I think some of these changes are really silly or plain wrong
("Linux-only kernel registers") and we should simply drop the rule
from the ARI.

> 2009-04-15  Pierre Muller  <muller.u-strasbg.fr>
> 
> 	ARI fix: GNU/Linux rule in comments.
> 	* amd64-tdep.c (amd64_displaced_step_fixup): Specify Linux kernel.
> 	* i386-tdep.c (i386_displaced_step_fixup): Idem.
> 	* i386-tdep.h (I386_MAX_INSN_LEN): Idem.
> 	* ppc-linux-tdep.c (ppc_linux_supply_gregset): Idem.
> 	(_initialize_ppc_linux_tdep): Idem.
> 	* ppc-linux-tdep.h: Idem.
> 	* linux-nat.c: Idem in starting comments.
> 	(linux_nat_filter_event): Idem.
> 
> Index: amd64-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
> retrieving revision 1.58
> diff -u -p -r1.58 amd64-tdep.c
> --- amd64-tdep.c	17 Feb 2009 06:14:16 -0000	1.58
> +++ amd64-tdep.c	14 Apr 2009 22:55:47 -0000
> @@ -1273,7 +1273,7 @@ amd64_displaced_step_fixup (struct gdbar
>      }
>  
>    /* The list of issues to contend with here is taken from
> -     resume_execution in arch/x86/kernel/kprobes.c, Linux 2.6.28.
> +     resume_execution in arch/x86/kernel/kprobes.c, Linux kernel 2.6.28.
>       Yay for Free Software!  */
>  
>    /* Relocate the %rip back to the program's instruction stream,
> Index: i386-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-tdep.c,v
> retrieving revision 1.269
> diff -u -p -r1.269 i386-tdep.c
> --- i386-tdep.c	17 Feb 2009 06:14:16 -0000	1.269
> +++ i386-tdep.c	14 Apr 2009 22:55:48 -0000
> @@ -430,7 +430,7 @@ i386_displaced_step_fixup (struct gdbarc
>                          paddr_nz (from), paddr_nz (to), insn[0], insn[1]);
>  
>    /* The list of issues to contend with here is taken from
> -     resume_execution in arch/i386/kernel/kprobes.c, Linux 2.6.20.
> +     resume_execution in arch/i386/kernel/kprobes.c, Linux kernel 2.6.20.
>       Yay for Free Software!  */
>  
>    /* Relocate the %eip, if necessary.  */
> Index: i386-tdep.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-tdep.h,v
> retrieving revision 1.57
> diff -u -p -r1.57 i386-tdep.h
> --- i386-tdep.h	4 Feb 2009 14:49:41 -0000	1.57
> +++ i386-tdep.h	14 Apr 2009 22:55:48 -0000
> @@ -165,7 +165,7 @@ extern struct type *i386_sse_type (struc
>  #define I386_SEL_KPL	0x0000	/* Kernel Privilige Level. */
>  
>  /* The length of the longest i386 instruction (according to
> -   include/asm-i386/kprobes.h in Linux 2.6.  */
> +   include/asm-i386/kprobes.h in Linux kernel 2.6.  */
>  #define I386_MAX_INSN_LEN (16)
>  
>  /* Functions exported from i386-tdep.c.  */
> Index: ppc-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
> retrieving revision 1.110
> diff -u -p -r1.110 ppc-linux-tdep.c
> --- ppc-linux-tdep.c	22 Feb 2009 01:02:19 -0000	1.110
> +++ ppc-linux-tdep.c	14 Apr 2009 22:55:48 -0000
> @@ -659,7 +659,7 @@ ppc64_linux_convert_from_func_ptr_addr (
>    return addr;
>  }
>  
> -/* Wrappers to handle Linux-only registers.  */
> +/* Wrappers to handle Linux-only kernel registers.  */
>  
>  static void
>  ppc_linux_supply_gregset (const struct regset *regset,
> @@ -1175,7 +1175,7 @@ _initialize_ppc_linux_tdep (void)
>    gdbarch_register_osabi (bfd_arch_rs6000, bfd_mach_rs6k, GDB_OSABI_LINUX,
>                           ppc_linux_init_abi);
>  
> -  /* Initialize the Linux target descriptions.  */
> +  /* Initialize the Linux kernel target descriptions.  */
>    initialize_tdesc_powerpc_32l ();
>    initialize_tdesc_powerpc_altivec32l ();
>    initialize_tdesc_powerpc_vsx32l ();
> Index: ppc-linux-tdep.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/ppc-linux-tdep.h,v
> retrieving revision 1.4
> diff -u -p -r1.4 ppc-linux-tdep.h
> --- ppc-linux-tdep.h	3 Jan 2009 05:57:53 -0000	1.4
> +++ ppc-linux-tdep.h	14 Apr 2009 22:55:48 -0000
> @@ -38,7 +38,7 @@ enum {
>  /* Return 1 if PPC_ORIG_R3_REGNUM and PPC_TRAP_REGNUM are usable.  */
>  int ppc_linux_trap_reg_p (struct gdbarch *gdbarch);
>  
> -/* Linux target descriptions.  */
> +/* Linux kernel target descriptions.  */
>  extern struct target_desc *tdesc_powerpc_32l;
>  extern struct target_desc *tdesc_powerpc_altivec32l;
>  extern struct target_desc *tdesc_powerpc_vsx32l;
> Index: linux-nat.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/linux-nat.c,v
> retrieving revision 1.128
> diff -u -p -r1.128 linux-nat.c
> --- linux-nat.c	1 Apr 2009 19:07:50 -0000	1.128
> +++ linux-nat.c	14 Apr 2009 22:55:50 -0000
> @@ -70,7 +70,7 @@ When waiting for an event in a specific 
>  the specific pid, and not passing WNOHANG.
>  
>  When waiting for an event in all threads, waitpid is not quite good. Prior
> to
> -version 2.4, Linux can either wait for event in main thread, or in
> secondary
> +version 2.4, Linux kernel can either wait for event in main thread, or in
> secondary
>  threads. (2.4 has the __WALL flag).  So, if we use blocking waitpid, we
> might
>  miss an event.  The solution is to use non-blocking waitpid, together with
>  sigsuspend.  First, we use non-blocking waitpid to get an event in the main
> 
> @@ -2625,7 +2625,7 @@ linux_nat_filter_event (int lwpid, int s
>      {
>        /* If this is the main thread, we must stop all threads and verify
>  	 if they are still alive.  This is because in the nptl thread model
> -	 on Linux 2.4, there is no signal issued for exiting LWPs
> +	 on Linux kernel 2.4, there is no signal issued for exiting LWPs
>  	 other than the main thread.  We only get the main thread exit
>  	 signal once all child threads have already exited.  If we
>  	 stop all the threads and use the stop_wait_callback to check
> 

Re: [RFC] GDB ARIndex Linux rule cleanup

[Pedro Alves]

On Wednesday 15 April 2009 00:22:36, Mark Kettenis wrote:

> I think some of these changes are really silly or plain wrong
> ("Linux-only kernel registers") and we should simply drop the rule
> from the ARI.

I agree.  There's no scope for confusion over what "Linux" is
refering to here.

-- 
Pedro Alves

Re: [RFC] GDB ARIndex Linux rule cleanup

[Joel Brobecker]

> I agree.  There's no scope for confusion over what "Linux" is
> refering to here.

I would tend to agree too. But I'm wondering if this is not
a requirement from RMS for all GNU projects...

-- 
Joel

RE: [RFC] GDB ARIndex Linux rule cleanup

[Pierre Muller]

Maybe,

see
http://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

Pierre

> -----Message d'origine-----
> De : Joel Brobecker [mailto:brobecker@adacore.com]
> Envoyé : Wednesday, April 15, 2009 1:41 AM
> À : Pedro Alves
> Cc : gdb-patches@sourceware.org; Mark Kettenis; muller@ics.u-
> strasbg.fr; gdb@sourceware.org; eliz@gnu.org
> Objet : Re: [RFC] GDB ARIndex Linux rule cleanup
> 
> > I agree.  There's no scope for confusion over what "Linux" is
> > refering to here.
> 
> I would tend to agree too. But I'm wondering if this is not
> a requirement from RMS for all GNU projects...
> 
> --
> Joel

Re: [RFC] GDB ARIndex Linux rule cleanup

[Eli Zaretskii]

> Date: Tue, 14 Apr 2009 16:41:26 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org, Mark Kettenis <mark.kettenis@xs4all.nl>, 	muller@ics.u-strasbg.fr, gdb@sourceware.org, eliz@gnu.org
> 
> > I agree.  There's no scope for confusion over what "Linux" is
> > refering to here.
> 
> I would tend to agree too. But I'm wondering if this is not
> a requirement from RMS for all GNU projects...

The requirement is _not_ to have the word "kernel" literally where one
talks about the Linux kernel.  The requirement is to use "GNU/Linux"
where one talks about something that is _not_ the kernel.

So, in the cases where Pierre suggested to add the word "kernel", that
is not needed.  It is enough to establish that the text is about the
Linux kernel, and not about GNU/Linux as a system.

How to express that in Awk-ish, is another matter.  Judging just by
the cases in Pierre's patch, it sounds like having on the same text
line words like "kernel", "register", "target", and a numeric version
string X.Y are telltale signs that the kernel is being discussed.
Perhaps we can start with these words, and add more as needed in the
future.

Re: [RFC] GDB ARIndex Linux rule cleanup

[Ulrich Weigand]

Pierre Muller wrote:

> Index: ppc-linux-tdep.c
> ===================================================================

> -/* Wrappers to handle Linux-only registers.  */
> +/* Wrappers to handle Linux-only kernel registers.  */

> -  /* Initialize the Linux target descriptions.  */
> +  /* Initialize the Linux kernel target descriptions.  */

> Index: ppc-linux-tdep.h
> ===================================================================

> -/* Linux target descriptions.  */
> +/* Linux kernel target descriptions.  */


It seems to me that in *those* cases, we should actually use
GNU/Linux instead -- this is talking about GDB target support
for the GNU/Linux operating system on PowerPC, and not specifically
related to the kernel only (for example, those target descriptions
are also used when analysing a core file on a remote system).

Compare for example the usage in linux-nat.c:

/* Create a prototype generic GNU/Linux target.  


The other instances in your patch, where a kernel version
is specifically named, clearly refer to the Linux kernel.

I'd be fine with adding "kernel" to the text here; but I
also agree with Eli's suggestion that it might be even 
better to have the ARI script recognize use of a version
number ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] GDB ARIndex Linux rule cleanup

[Pedro Alves]

On Wednesday 15 April 2009 15:00:39, Ulrich Weigand wrote:
> > Index: ppc-linux-tdep.h
> > ===================================================================
> 
> > -/* Linux target descriptions.  */
> > +/* Linux kernel target descriptions.  */
> 
> 
> It seems to me that in *those* cases, we should actually use
> GNU/Linux instead -- this is talking about GDB target support
> for the GNU/Linux operating system on PowerPC, and not specifically
> related to the kernel only (for example, those target descriptions
> are also used when analysing a core file on a remote system).

I disagree.  Everything in that file is related to register descriptions
and layouts defined by Linux, the kernel, what's in userland doesn't
affect any of it, or did I miss something?  Even if I built a system
comprising of a Linux kernel + all BSD userland, these constants and
offsets would still apply.

On Wednesday 15 April 2009 15:00:39, Ulrich Weigand wrote:
> /* Create a prototype generic GNU/Linux target.  

I'm of the oposite opinion.  I consider *this* a bug.  This
file (linux-nat.c) concerns about abstracting of ptrace and /proc
interfaces, which are kernel defined interfaces.

> The other instances in your patch, where a kernel version
> is specifically named, clearly refer to the Linux kernel.
> 
> I'd be fine with adding "kernel" to the text here; but I
> also agree with Eli's suggestion that it might be even 
> better to have the ARI script recognize use of a version
> number ...

I re-suggest what Mark suggested, that we drop the ARI rule.
It is only inventing work.  I suggest we apply the Linux vs
GNU/Linux judgement at patch review time, and be mostly careful
in documentation and user visible strings, not in code directly
interfacing with kernel data structures and interfaces.

-- 
Pedro Alves

Re: [RFC] GDB ARIndex Linux rule cleanup

[Ulrich Weigand]

Pedro Alves wrote:

> On Wednesday 15 April 2009 15:00:39, Ulrich Weigand wrote:
> > It seems to me that in *those* cases, we should actually use
> > GNU/Linux instead -- this is talking about GDB target support
> > for the GNU/Linux operating system on PowerPC, and not specifically
> > related to the kernel only (for example, those target descriptions
> > are also used when analysing a core file on a remote system).
> 
> I disagree.  Everything in that file is related to register descriptions
> and layouts defined by Linux, the kernel, what's in userland doesn't
> affect any of it, or did I miss something?  Even if I built a system
> comprising of a Linux kernel + all BSD userland, these constants and
> offsets would still apply.

> > /* Create a prototype generic GNU/Linux target.=20=20
> 
> I'm of the oposite opinion.  I consider *this* a bug.  This
> file (linux-nat.c) concerns about abstracting of ptrace and /proc
> interfaces, which are kernel defined interfaces.

See my reply to Eli ... lots of target-specific information is *not*
related to the Linux kernel, but the platform ABI, libc, libpthread ...

> > The other instances in your patch, where a kernel version
> > is specifically named, clearly refer to the Linux kernel.
> >=20
> > I'd be fine with adding "kernel" to the text here; but I
> > also agree with Eli's suggestion that it might be even=20
> > better to have the ARI script recognize use of a version
> > number ...
> 
> I re-suggest what Mark suggested, that we drop the ARI rule.
> It is only inventing work.  I suggest we apply the Linux vs
> GNU/Linux judgement at patch review time, and be mostly careful
> in documentation and user visible strings, not in code directly
> interfacing with kernel data structures and interfaces.

I agree that user-visible instances are certainly much more
important, and I don't really have any strong opinion on whether
there is any need to enforce the GNU/Linux rule in source code
comments.

My point was simply that (to me, at least) there is clear evidence
of a pre-existing convention in GDB sources (all references to a
GDB "target" refer in fact to the target OS, and thus GNU/Linux
should be used), and those three places in ppc-linux* that Pierre
identified were the only deviations from that convention.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] GDB ARIndex Linux rule cleanup

[Pedro Alves]

On Wednesday 15 April 2009 16:32:16, Ulrich Weigand wrote:
> > /* Create a prototype generic GNU/Linux target.=20=20
> Pedro wrote:
> > I'm of the oposite opinion.  I consider *this* a bug.  This
> > file (linux-nat.c) concerns about abstracting of ptrace and /proc
> > interfaces, which are kernel defined interfaces.
> 
> See my reply to Eli ... lots of target-specific information is *not*
> related to the Linux kernel, but the platform ABI, libc, libpthread ...

We're diverging a lot.  None of that matters to linux-nat.c.
The word "target" is seriously overloaded in GDB.  It means different
things depending on context.  ABI specific details, platform abis, and libc
issues are handled elsewhere...  The "prototype generic target" that comment
is refering to, is to the fact that this file is then inherited and
specialized by an arch specific layer (i386-linux-nat.c, etc.)...

Really, the ARI rule is only inventing work, because it have all
the context humans do.  Some artificial heuristic will only
byte us from time to time for no good.  I'd be surprised to hear
that someone (a human) reading or hacking on GDB's code was
confused by any of this.

Anyway, I'm out of here.

-- 
Pedro Alves

Re: [RFC] GDB ARIndex Linux rule cleanup

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 16:00:39 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: brobecker@adacore.com ('Joel Brobecker'), gdb-patches@sourceware.org,
>         gdb@sourceware.org, eliz@gnu.org ('Eli Zaretskii')
> 
> Pierre Muller wrote:
> 
> > Index: ppc-linux-tdep.c
> > ===================================================================
> 
> > -/* Wrappers to handle Linux-only registers.  */
> > +/* Wrappers to handle Linux-only kernel registers.  */
> 
> > -  /* Initialize the Linux target descriptions.  */
> > +  /* Initialize the Linux kernel target descriptions.  */
> 
> > Index: ppc-linux-tdep.h
> > ===================================================================
> 
> > -/* Linux target descriptions.  */
> > +/* Linux kernel target descriptions.  */
> 
> 
> It seems to me that in *those* cases, we should actually use
> GNU/Linux instead -- this is talking about GDB target support
> for the GNU/Linux operating system on PowerPC, and not specifically
> related to the kernel only (for example, those target descriptions
> are also used when analysing a core file on a remote system).

I think GDB's "target" is always the OS kernel, not the OS itself.

The distinction FSF asks for is between the GNU/Linux as a whole
system, which includes all the main applications and libraries, and
Linux as the bare-bones OS.  GDB targets the latter, not the former.

> Compare for example the usage in linux-nat.c:
> 
> /* Create a prototype generic GNU/Linux target.  

That's a mistake, IMO.  There's no need for GNU here.

Re: [RFC] GDB ARIndex Linux rule cleanup

[Daniel Jacobowitz]

On Wed, Apr 15, 2009 at 05:24:50PM +0300, Eli Zaretskii wrote:
> The distinction FSF asks for is between the GNU/Linux as a whole
> system, which includes all the main applications and libraries, and
> Linux as the bare-bones OS.  GDB targets the latter, not the former.

I agree.  For accuracy's sake, there are some exceptions; this is a
difference between linux-nat.c and linux-thread-db.c.  The latter
targets a GLIBC (and thus GNU) interface.  Although a very similar
interface is present on Solaris, and although uClibc (not a GNU
project although containing some GNU code) also implements it, the
file is primarily targeting GLIBC.

But most of our Linux support doesn't have this issue.  As you've
said, mostly we're concerned with the kernel.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] GDB ARIndex Linux rule cleanup

[Ulrich Weigand]

Eli Zaretskii wrote:

> I think GDB's "target" is always the OS kernel, not the OS itself.
>
> The distinction FSF asks for is between the GNU/Linux as a whole
> system, which includes all the main applications and libraries, and
> Linux as the bare-bones OS.  GDB targets the latter, not the former.

Huh?  I'd say a large part of what makes up a GDB target is unrelated
to the OS kernel:
- Processor properties (register names/types/groups)
- ABI elements (data types, function calling convention, stack unwinding,
  C++ ABI, platform-specific debug format details, ...)
- Shared library support, thread support (those may depend on kernel
  details, but may also -in particular on Linux- depend on strictly
  user-space library-implemented details ...)

If you were to write a program using a completely different user-space
ABI, it might run just fine on the Linux kernel, but GDB configured
for a -linux target would not really be able to successfully debug the
program.

It seems to me that configuring GDB for, say, the powerpc-linux target,
has the effect of preparing GDB to debug programs on the GNU/Linux OS
on the PowerPC platform, assuming the GNU/Linux ABI for the platform
as well as the core GNU/Linux system libraries (libc, ld.so, libpthread)
to be used, of course *in addition* to the Linux kernel.

> > Compare for example the usage in linux-nat.c:
> > 
> > /* Create a prototype generic GNU/Linux target.  
> 
> That's a mistake, IMO.  There's no need for GNU here.

This is common usage throughout the Linux target and native files.
Even looking just at the very first lines of those files:

[uweigand@blc4eb184639574 gdb]$ head -1 *-linux-tdep.c | grep Linux
/* Target-dependent code for GNU/Linux on Alpha.
/* Target-dependent code for GNU/Linux x86-64.
/* GNU/Linux on ARM target support.
/* Target-dependent code for GNU/Linux running on the Fujitsu FR-V,
/* Target-dependent code for GNU/Linux running on PA-RISC, for GDB.
/* Target-dependent code for GNU/Linux i386.
/* Target-dependent code for GNU/Linux m32r.
/* Target-dependent code for GNU/Linux on MIPS processors.
/* Target-dependent code for GNU/Linux Super-H.
/* Target-dependent code for GNU/Linux UltraSPARC.
/* Target-dependent code for GNU/Linux SPARC.
/* Target-dependent code for GNU/Linux on Xtensa processors.
[uweigand@blc4eb184639574 gdb]$ head -1 *-linux-nat.c | grep Linux
/* Low level Alpha GNU/Linux interface, for GDB when running native.
/* Native-dependent code for GNU/Linux x86-64.
/* GNU/Linux on ARM native support.
/* Functions specific to running GDB native on HPPA running GNU/Linux.
/* Native-dependent code for GNU/Linux i386.
/* Native-dependent code for GNU/Linux m32r.
/* Native-dependent code for GNU/Linux on MIPS processors.
/* PPC GNU/Linux native support.
/* Native-dependent code for GNU/Linux UltraSPARC.
/* Native-dependent code for GNU/Linux SPARC.
/* Xtensa GNU/Linux native support.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] GDB ARIndex Linux rule cleanup

[Mark Kettenis]

Can we please stop this pointless discussion about a silly political
argument and get back to actually make GDB a better tool?

Re: [RFC] GDB ARIndex Linux rule cleanup

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 17:32:52 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: eliz@gnu.org, muller@ics.u-strasbg.fr, brobecker@adacore.com,
>         gdb-patches@sourceware.org, gdb@sourceware.org
> 
> Can we please stop this pointless discussion about a silly political
> argument and get back to actually make GDB a better tool?

It's not silly, at least not to me.

To avoid such arguments in the future, I think we need to agree once
and for all on some rules and codify them.

Re: [RFC] GDB ARIndex Linux rule cleanup

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 17:23:18 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: muller@ics.u-strasbg.fr, brobecker@adacore.com, gdb-patches@sourceware.org,
>         gdb@sourceware.org
> 
> Eli Zaretskii wrote:
> 
> > I think GDB's "target" is always the OS kernel, not the OS itself.
> >
> > The distinction FSF asks for is between the GNU/Linux as a whole
> > system, which includes all the main applications and libraries, and
> > Linux as the bare-bones OS.  GDB targets the latter, not the former.
> 
> Huh?  I'd say a large part of what makes up a GDB target is unrelated
> to the OS kernel:
> - Processor properties (register names/types/groups)

That's hardware, and as such, unrelated to our discussion.

> - ABI elements (data types, function calling convention, stack unwinding,
>   C++ ABI, platform-specific debug format details, ...)

Which has nothing to do with GNU.

> - Shared library support, thread support (those may depend on kernel
>   details, but may also -in particular on Linux- depend on strictly
>   user-space library-implemented details ...)

That's not part of the ``target'', in the sense that we were talking
about.

> If you were to write a program using a completely different user-space
> ABI, it might run just fine on the Linux kernel, but GDB configured
> for a -linux target would not really be able to successfully debug the
> program.

We are talking about a specific file, not about the whole of GDB built
for native debugging.

> > > Compare for example the usage in linux-nat.c:
> > > 
> > > /* Create a prototype generic GNU/Linux target.  
> > 
> > That's a mistake, IMO.  There's no need for GNU here.
> 
> This is common usage throughout the Linux target and native files.
> Even looking just at the very first lines of those files:

Because people who don't understand the essence of the distinction
between the Linux kernel and GNU/Linux as a system get scared and put
the "GNU" part everywhere, lest they err on the wrong side.

Re: [RFC] GDB ARIndex Linux rule cleanup

[Ulrich Weigand]

Eli Zaretskii wrote:
> > Eli Zaretskii wrote:
> > > I think GDB's "target" is always the OS kernel, not the OS itself.
> > >
> > > The distinction FSF asks for is between the GNU/Linux as a whole
> > > system, which includes all the main applications and libraries, and
> > > Linux as the bare-bones OS.  GDB targets the latter, not the former.
> > 
> > Huh?  I'd say a large part of what makes up a GDB target is unrelated
> > to the OS kernel:
> > - Processor properties (register names/types/groups)
> 
> That's hardware, and as such, unrelated to our discussion.
> 
> > - ABI elements (data types, function calling convention, stack unwinding,
> >   C++ ABI, platform-specific debug format details, ...)
> 
> Which has nothing to do with GNU.
> 
> > - Shared library support, thread support (those may depend on kernel
> >   details, but may also -in particular on Linux- depend on strictly
> >   user-space library-implemented details ...)
> 
> That's not part of the ``target'', in the sense that we were talking
> about.

As the whole discussion started over a -tdep.c file, I was intending to
refer to a "target architecture", i.e. a gdbarch structure (which also
more or less corresponds to what the user specifies as --target= when
configuring GDB).  This struct does indeed contain all the elements I
mention above; and my point was simply that its contents are influenced
by the full target operating system (ABI, system libraries, kernel),
and *not* solely the kernel.

The word "target" is unfortunately quite overloaded; when referring to
the "target stack", the situation is somewhat different, but even there
I'd argue that, say, the "Linux native target" implements support for
running GDB natively on the GNU/Linux operating system, not just the kernel
(e.g. due to native thread and shared library support).

> > If you were to write a program using a completely different user-space
> > ABI, it might run just fine on the Linux kernel, but GDB configured
> > for a -linux target would not really be able to successfully debug the
> > program.
> 
> We are talking about a specific file, not about the whole of GDB built
> for native debugging.

Yes, the ppc-linux-tdep.c file, which defines the gdbarch struct to be used
when debugging an application built for GNU/Linux on the PowerPC platform,
in either native, remote, or core file debugging mode.

In fact, in this specific file, some elements of the gdbarch struct are
clearly kernel-related (e.g. the ppc_linux_write_pc method to properly
restart interrupted system calls, or the signal trampoline unwinders), some
elements have nothing whatsoever to do with the kernel (e.g. the
ppc_linux_memory_remove_breakpoint method that deals with the fact that
ld.so on powerpc modifies code, or the ppc64_skip_trampoline_code method
which recognizes linker-generated stubs, or the
ppc64_linux_convert_from_func_ptr_addr method that interprets the function
pointer ABI), and some could be considered either way (e.g. the core file
register set definitions -- a core file may be generated by the kernel,
but also other tools, including GDB itself).


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] GDB ARIndex Linux rule cleanup

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 19:34:08 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: muller@ics.u-strasbg.fr, brobecker@adacore.com, gdb-patches@sourceware.org,
>         gdb@sourceware.org
> 
> Yes, the ppc-linux-tdep.c file, which defines the gdbarch struct to be used
> when debugging an application built for GNU/Linux on the PowerPC platform,
> in either native, remote, or core file debugging mode.
> 
> In fact, in this specific file, some elements of the gdbarch struct are
> clearly kernel-related (e.g. the ppc_linux_write_pc method to properly
> restart interrupted system calls, or the signal trampoline unwinders), some
> elements have nothing whatsoever to do with the kernel (e.g. the
> ppc_linux_memory_remove_breakpoint method that deals with the fact that
> ld.so on powerpc modifies code, or the ppc64_skip_trampoline_code method
> which recognizes linker-generated stubs, or the
> ppc64_linux_convert_from_func_ptr_addr method that interprets the function
> pointer ABI), and some could be considered either way (e.g. the core file
> register set definitions -- a core file may be generated by the kernel,
> but also other tools, including GDB itself).

The point is that the elements that are unrelated to the Linux kernel
are also unrelated to GNU.

Re: [RFC] GDB ARIndex Linux rule cleanup

[Ulrich Weigand]

Eli Zaretskii wrote:
> > Date: Wed, 15 Apr 2009 19:34:08 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > Cc: muller@ics.u-strasbg.fr, brobecker@adacore.com, gdb-patches@sourceware.org,
> >         gdb@sourceware.org
> > 
> > Yes, the ppc-linux-tdep.c file, which defines the gdbarch struct to be used
> > when debugging an application built for GNU/Linux on the PowerPC platform,
> > in either native, remote, or core file debugging mode.
> > 
> > In fact, in this specific file, some elements of the gdbarch struct are
> > clearly kernel-related (e.g. the ppc_linux_write_pc method to properly
> > restart interrupted system calls, or the signal trampoline unwinders), some
> > elements have nothing whatsoever to do with the kernel (e.g. the
> > ppc_linux_memory_remove_breakpoint method that deals with the fact that
> > ld.so on powerpc modifies code, or the ppc64_skip_trampoline_code method
> > which recognizes linker-generated stubs, or the
> > ppc64_linux_convert_from_func_ptr_addr method that interprets the function
> > pointer ABI), and some could be considered either way (e.g. the core file
> > register set definitions -- a core file may be generated by the kernel,
> > but also other tools, including GDB itself).
> 
> The point is that the elements that are unrelated to the Linux kernel
> are also unrelated to GNU.

I was replying to your statement that 

  I think GDB's "target" is always the OS kernel, not the OS itself.

with the point that all those elements are related to, and in fact defined
by, the *target operating system*; the OS defines the ABI applications
need to use, and in the GNU/Linux case, even provides the toolchain and
system libraries that implement those elements.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com