RE: [RFA] gdbadmin/ss/gdb_find.sh cleanup

Pierre Muller
2009-04-22T21:41:50Z

Hi Joel,

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Wednesday, April 22, 2009 7:57 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA] gdbadmin/ss/gdb_find.sh cleanup
>
> > -name signals -prune -o \
>
> I can't find a "signals" directory. Can you double-check and remove
> this line if I'm right? (if it makes sense to you too)

Everything from signals directory seems to have been moved to
common directory by Doug Evans see ChangeLog entry from 2009-03-01.

I never use -P option for 'cvs up'
and thus have a lot of empty directories lying around!

> > -name testsuite -prune -o \
> > -name gdbserver -prune -o \
>
> I wonder if we want to start tracking the gdbserver sources as well.
> Just a thought...
>
> > -name gnulib -prune -o \
> > -name rdi-share -prune -o \
>
> Can't find this directory either...
>
> > -name remote-mips.c -prune -o \
>
> This file started being excluded in Jan 2005. There's definitely
> been some activity on the associated target, so I'm thinking it might
> make sense to stop excluding it.
>
> > 'sh64*' and 'remote-mips.c'
> > sh64* covers
> > gdb/sh64-tdep.c file
> > and
> > config/sh64 directory.
> Strange, I can't find that config/sh64 directory either.
>
Strange because there is a sh64 in gdb/config/CVS/entries
but on the other hand, when I do 'cvs up'
sh64 directory is not listed...

> > Why are those patterns excluded?
>
> Here what the CVS log says about the change that introduced the
> exclusion:
>
> revision 1.7
> date: 2004/08/03 13:09:19; author: cagney; state: Exp; lines: +9
> -2
> Ignore (hardwired) broken targets.
>
> Since then, it appears that Corinna Vinshen has done some work to
> revive the target. So we might again want to remove them from the
> exclusion list. To be checked with Corinna?
>
> > < -name ada-lex.c -prune -o \
>
> DanielJ specifically removed this file from the list. I'm not sure
> whether anything changed that would make us change our decision.
> This is a generated file - perhaps we should check the source .l
> file instead (which I think we do).
>
> > < -name cp-name-parser.c -prune -o \
>
> Same here. This is a generated file.
>
> > < -name stop-gdb.c -prune -o \
> > 19,21d15
> > < -name lynx-nat.c -prune -o \
> > < -name ppc-bdm.c -prune -o \
> > < -name ppc-bdm.c -prune -o \
> > 23,24d16
> > < -name remote-sds.c -prune -o \
> > < -name remote-sds.c -prune -o \
>
> The rest seems OK to me.
>
> --
> Joel

Below is the new version of gdb_find.sh
that I checked in:
(the diff file is just as big, so I send the new version directly)

Thanks, Joel,

Pierre

$ cat gdb_find.sh
#!/bin/sh

# A find that prunes files that GDB users shouldn't be interested in.

find "$@" \
-name testsuite -prune -o \
-name gdbserver -prune -o \
-name gnulib -prune -o \
-name osf-share -prune -o \
-name '*-stub.c' -prune -o \
-name '*-exp.c' -prune -o \
-name ada-lex.c -prune -o \
-name cp-name-parser.c -prune -o \
-name remote-mips.c -prune -o \
-type f -name '*.[lyhc]' -print