From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11893 invoked by alias); 17 Apr 2009 06:39:04 -0000 Received: (qmail 11884 invoked by uid 22791); 17 Apr 2009 06:39:03 -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.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Apr 2009 06:38:58 +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 n3H6cBZ2095779 ; Fri, 17 Apr 2009 08:38:12 +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 n3H6cBT6006449 ; Fri, 17 Apr 2009 08:38:11 +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 n3H6cAML031954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 17 Apr 2009 08:38:11 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: References: <001f01c9beec$934dd280$b9e97780$@u-strasbg.fr> <20090417001923.GQ7585@adacore.com> In-Reply-To: <20090417001923.GQ7585@adacore.com> Subject: RE: [PATCH] gdb_ari.sh cleanup Date: Fri, 17 Apr 2009 06:39:00 -0000 Message-ID: <000701c9bf27$14191e30$3c4b5a90$@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/msg00409.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: Friday, April 17, 2009 2:19 AM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [PATCH] gdb_ari.sh cleanup >=20 > > I did not handle two macros, because > > they are unused but are still present in docs: > > REGISTER_U_ADDR > > PROCESS_LINENUMBER_HOOK Yes , please do it as it seems that=20 at least for REGISTER_U_ADDR, it is not a=20 node that you can just remove directly. > Let's just remove them from the documentation. It's a very simple > change, but let me know if you'd like me to take care of it. >=20 > > Miscellaneous questions: > > 1a) Should the PARAMS rule be moved to code section? > > 1b) Same question for __FUNCTION__ rule. > > 1c) Idem for ARGSUSED >=20 > Does it really make a difference? If it helps you analyze the results, > then I'd say go for it. >=20 > > 1d) Idem for Whoops: this was ATTRIBUTE_UNUSED I will then move all those to ari_code type. =20 > (name missing?) >=20 > > 2) LITTLE_ENDIAN and BIG_ENDIAN still exists in configure, > > should I still remove the rule? >=20 > I don't think so. I don't know what the details are, but I'm wondering > whether the macros might be defined by the compiler, thus making it > possible for us to accidently reintroduce this usage again. I'd say, > let's keep the rule. OK, I leave these one in. =20 > > 3) HAVE_VFORK is still present in config.in > > should I keep the rule or should we remove it from config.in first? >=20 > We need to keep the rule. That macro is still used by gdb_vfork.h > and it is a valid use of that macro. In a way, this is very similar > to the use of "abort" - only very selected uses are allowed. OK, same here. Thanks for the answers, Pierre Muller Pascal language support maintainer for GDB