From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15915 invoked by alias); 15 Mar 2010 18:35:24 -0000 Received: (qmail 15899 invoked by uid 22791); 15 Mar 2010 18:35:24 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Mar 2010 18:35:19 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 201541B4036; Mon, 15 Mar 2010 18:35:18 +0000 (UTC) From: Mike Frysinger To: Joel Brobecker Subject: Re: [PATCH] sim: avoid TRACE redefine warnings Date: Mon, 15 Mar 2010 18:35:00 -0000 User-Agent: KMail/1.13.1 (Linux/2.6.33; KDE/4.4.1; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <1268599156-23584-1-git-send-email-vapier@gentoo.org> <201003150317.58516.vapier@gentoo.org> <20100315164934.GK3045@adacore.com> In-Reply-To: <20100315164934.GK3045@adacore.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12086898.i8SAWoxW3G"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003151435.17406.vapier@gentoo.org> X-IsSubscribed: yes 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: 2010-03/txt/msg00552.txt.bz2 --nextPart12086898.i8SAWoxW3G Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 2268 On Monday 15 March 2010 12:49:34 Joel Brobecker wrote: > > as i mentioned in the first e-mail, "TRACE" is defined on the command > > line, so any macro named "TRACE" has to be renamed. >=20 > I understood why you had to rename the macro. The problem is that > I'm wondering what this macro is supposed to be used for. It's important > because I suspect the change that you made might be incorrect, depending > on the answer to the question above. For instance, I suspect that the > use of the TRACE macro in that file might be related to > --enable-sim-traces, and thus renaming TRACE to something else will break > that. >=20 > That's why, IMO, we need to: > - Understand how --enable-sim-traces work to see if it is related > to the use of this TRACE macro; > - Find out how to properly fix your problem; >=20 > If you want, I can try doing some digging, but I think it's going to be > a while before I can get to it, which is why I'm giving you as much info > as I have (I really do not have much sim experience, but apparently we > are short in reviewers for the sim code). i'm not sure how the code today could possibly result in working behavior=20 regardless of what is done in the autoconf stages. the sim-traces configur= e=20 option adds -DTRACE=3D0 or -DTRACE=3D1 to the command line. the hw-propert= ies.c=20 then defines TRACE() after including everything. so there is no chance for= =20 the -DTRACE logic to affect things here -- TRACE is always redefined from a= =20 0/1 value (or anything else) to a macro that expands into nothing. if i had to divine intention, this is old code that was forgotten in the=20 HW_TRACE() transition and so the correct fix would be: - delete the #define TRACE - change all TRACE call sites to HW_TRACE - change the non-existent "trace_devices" to "me" this would have the code style match the rest of hw code in common/. i didnt go this route originally because the sim/ dir is lacking in=20 documentation, so i didnt want to break something inadvertently. i'd rathe= r=20 have someone who knows the code ACK the idea. but if the developer base fo= r=20 sim/ is as slim as the documentation, i'll be a bit more bold in my proposa= ls=20 based on my recent sim/ work for the Blackfin processor. -mike --nextPart12086898.i8SAWoxW3G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABAgAGBQJLnn3lAAoJEEFjO5/oN/WBx8sP/0Z+0jh/KhjrYa5J7P+oMCn3 prxXZ6FnbdVlGTJcMVZUdJjEFZ6bh+RbaKo3rTXK0ufuVEM2efWRcGWiXQd2/Tqu l5X7X2TqHrmF0nbY1b5SxdCmbpPusY/4TSP1MFFq7U7wV1DcbZY2WND/65ZGz3f6 ZT8fjFqSvzsxbq016DQ0/vRNH6/FkCNLzATY6fIW4WXN2EOolupagMCCNupFBCUx ITFBVnsAl3V4Ov9Mmz+RQFlJMdPrzbmN3ZW4+iWpkZfM3BV7FlTpAN6tS7SB5tCf JRwrSazuUbvxA0v2h8Rdf/nBTqZ0PE1MpeuOVYNx/xtM8SoFImNivqvJ8aQlS1Xb g+eYzwIh12zggiktMFlZILr2cbNsbmdLSXIqBUB+RSgRhYsR8kRo1INQqkOWkW/X pPx7IlOkdDWb1iJwIl/GTuskbpbP3BnU4Qiv4Nsw2vEC5qr0G7pztJ8VusqPT5qT QbRp/vFWTe2u6DkpqgB7umdtMCc7vmd22IdKcQPhs6LrLU3gnxpYUDia41aZGxgi MDDs1snp9k69uzpfocoWZXBi7e6hJPQ8QAmpMkUJNkf9Jpa3bFbFNoBd+4i9o6I3 dQ50dXSb45L1f9+7/uCku/Iufj4J354FG6VGbAJbCW7eKZNZJ1JHMflmThvLfDRf 3Zpxvv5CuXpmOoKcoA69 =ybTz -----END PGP SIGNATURE----- --nextPart12086898.i8SAWoxW3G--