From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6993 invoked by alias); 22 Apr 2009 21:41:50 -0000 Received: (qmail 6984 invoked by uid 22791); 22 Apr 2009 21:41:48 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Apr 2009 21:41:41 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n3MLepxY036029 ; Wed, 22 Apr 2009 23:40:51 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [IPv6:2001:660:2402:d::10]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n3MLepjQ030955 ; Wed, 22 Apr 2009 23:40:51 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n3MLeoHG032275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 22 Apr 2009 23:40:51 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: References: <000b01c9c31d$d0ecfd70$72c6f850$@u-strasbg.fr> <20090422175643.GA22514@adacore.com> In-Reply-To: <20090422175643.GA22514@adacore.com> Subject: RE: [RFA] gdbadmin/ss/gdb_find.sh cleanup Date: Wed, 22 Apr 2009 21:41:00 -0000 Message-ID: <001601c9c393$04ef72e0$0ece58a0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00615.txt.bz2 Hi Joel, > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoy=E9=A0: Wednesday, April 22, 2009 7:57 PM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFA] gdbadmin/ss/gdb_find.sh cleanup >=20 > > -name signals -prune -o \ >=20 > 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 \ >=20 > I wonder if we want to start tracking the gdbserver sources as well. > Just a thought... >=20 > > -name gnulib -prune -o \ > > -name rdi-share -prune -o \ >=20 > Can't find this directory either... >=20 > > -name remote-mips.c -prune -o \ >=20 > 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. >=20 > > '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. >=20 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? >=20 > Here what the CVS log says about the change that introduced the > exclusion: >=20 > revision 1.7 > date: 2004/08/03 13:09:19; author: cagney; state: Exp; lines: +9 > -2 > Ignore (hardwired) broken targets. >=20 > 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? >=20 > > < -name ada-lex.c -prune -o \ >=20 > 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). >=20 > > < -name cp-name-parser.c -prune -o \ >=20 > Same here. This is a generated file. >=20 > > < -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 \ >=20 > The rest seems OK to me. >=20 > -- > 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