From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112663 invoked by alias); 24 Feb 2015 04:52:00 -0000 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 Received: (qmail 112652 invoked by uid 89); 24 Feb 2015 04:52:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Feb 2015 04:51:58 +0000 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 8C22834095D; Tue, 24 Feb 2015 04:51:54 +0000 (UTC) Date: Tue, 24 Feb 2015 04:52:00 -0000 From: Mike Frysinger To: James Bowman Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH, FT32] gdb and sim support Message-ID: <20150224045154.GE13523@vapier> Mail-Followup-To: James Bowman , "gdb-patches@sourceware.org" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o0ZfoUVt4BxPQnbU" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00686.txt.bz2 --o0ZfoUVt4BxPQnbU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2747 On 23 Feb 2015 10:40, James Bowman wrote: > > > 2014-02-03 James Bowman > > >=20 > > > * gdb/Makefile.in, gdb/configure.tgt: FT32 target added > > > * sim/configure.tgt: FT32 target added > > > * sim/configure: Regenerated > > > * sim/ft32/configure: Regenerated > > > * gdb/ft32-tdep.c,h: Support FT32 > > > * sim/ft32/*: FT32 simulator > >=20 > > notes: > > - ChangeLog entries are split up across dirs >=20 > Do you mean I should not split? Organize in some other way? see my patch here as an example: https://sourceware.org/ml/gdb-patches/2014-03/msg00173.html > > where's the testsuite man ? :) it should be trivial to start one with = .s > > files -- just look at sim/testsuite/sim/. otherwise there's no way to= keep > > regressions from slipping in. >=20 > Good idea. We are currently running the gcc testsuite on the simulator > as our regression test. Would it be OK if I defer, and add a sim > testsuite after this submit? that's what everyone says ;). the trouble with having no sim testsuite is = that=20 people (like me) only use the sim testsuite to verify common/arch changes d= on't=20 break things. you don't need a comphrensive one, just one or two basic thi= ngs.=20=20 that way we at least know the sim isn't completely hosed. > > > +/* Use an invalid address value as 'not available' marker. */ > > > +enum { REG_UNAVAIL =3D (CORE_ADDR) -1 }; >=20 > This is actually the value -1 being cast. I have rewritten the line to > make this clearer. ah sorry about that > > since you're a new port, you should start with SIM_AC_OPTION_WARNINGS e= nabled.=20=20 > > obviously that also means cleaning up all the warnings generated in the= ft32/=20 > > subdir once you do :). >=20 > Done - it now compiles without warnings. It would be nice to be able to > build it with warnings as errors. the functionality is in place, but it's disabled atm because the sim code h= as a=20 lot of legacy that needs cleaning. although might be good to bite that bul= let=20 now and uncomment the lines in common/acinclude.m4 that disables it. > > > --- /dev/null > > > +++ b/sim/ft32/interp.c > >=20 > > ideally you'd switch to sim-reg.o in your Makefile's SIM_OBJS ... that'= ll=20 > > provide these entry points. that would require also enabling sim-model= .o=20 > > & SIM_AC_OPTION_DEFAULT_MODEL support, but i don't think that'd be too = hard. > > if you look at bfin/machs.c and start at "sim_machs", i think you shoul= d be=20 > > able to track it down easily enough. >=20 > This change is causing me some trouble. OK to defer it until after the > main submit? mach/model support can wait i'll follow up once i review the actual code ;) -mike --o0ZfoUVt4BxPQnbU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU7ANqAAoJEEFjO5/oN/WBHmkP/1XmdVIssAeirjW0cMjwje/V PcZ69eSTIggEqBjk0PzQAwFMWxutP3J8p3ouWFoS19UXjH4i1uwlMtWzO2Ps0s4x DXaXk9aSxYU4zoPO1rLkxVOE3UP/j1DUwN9jhwagZOIEzgZYYckcK81BhhMyAbbx j7RfhWEihGvJDShixQktnAnTTchL/aHBNMTOv1/19Gc4ygyOrLt68wn6hS2c3Cmh A2QSw3rXu5BAf6GxYtrYn3D2yHwkGGeagA9EBLt4xvrLTH2ma6ev9FpyM/CHTOt+ uvLSO9pP2CNFRzev3EXc7nUyTLtgNEvVKQkOyn2rOkTYhT59xZJvmH7tfNEuSDEC PfO77PCeYJLAtbm/IvpJkX2xQXO3PafDUAScFBIbNs3u64tQxTj7Ib2UUvOvJB9Q LeBYFoGUzozOn+OfYEaLXwKy7n/uk5suuVZIs5qAY6M/D4DhRNQ0B+OEX0/b6Nz7 cm4NZl8b9NHiAR7PLGJa94i37wswsV2nts7BVTrOWS5on3MOFMhqFooKlSqaGTse +FKLOURBHwkClmzCdltDM34HKF5wE23nmvSolFIOqiXAQ0wdhSeK3qB23Stg22Vo pjDofgavAsav4/4O5euH5B1fnwTkNQnQKbmGvmtEE+BPGcV9W2bHfjOYBTHypqw5 0+aMGcFfaxJUrU0mU4DI =5DAD -----END PGP SIGNATURE----- --o0ZfoUVt4BxPQnbU--