From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36253 invoked by alias); 13 Mar 2015 00:15:03 -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 36216 invoked by uid 89); 13 Mar 2015 00:15:02 -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; Fri, 13 Mar 2015 00:15:01 +0000 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 1E8F63408C7; Fri, 13 Mar 2015 00:14:59 +0000 (UTC) Date: Fri, 13 Mar 2015 00:15:00 -0000 From: Mike Frysinger To: Jiri Gaisler Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 05/14] sim/erc32: Use memory_iread() function for instruction fetching. Message-ID: <20150313001459.GH877@vapier> Mail-Followup-To: Jiri Gaisler , gdb-patches@sourceware.org References: <1425244244-27709-1-git-send-email-jiri@gaisler.se> <1425244244-27709-6-git-send-email-jiri@gaisler.se> <20150302011544.GI19363@vapier> <55020795.4080009@gaisler.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="17/8oYur5Y32USnW" Content-Disposition: inline In-Reply-To: <55020795.4080009@gaisler.se> X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00386.txt.bz2 --17/8oYur5Y32USnW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 916 [re-adding cc] On 12 Mar 2015 22:39, Jiri Gaisler wrote: > On 02/03/15 02:15, Mike Frysinger wrote: > > On 01 Mar 2015 22:10, Jiri Gaisler wrote: > >> --- a/sim/erc32/erc32.c > >> +++ b/sim/erc32/erc32.c >=20 > >> + printf("Memory exception at %x (illegal address)\n", addr); > >=20 > > space after the printf > >=20 > > should this be writing to stderr ? >=20 > Not really. The exception occurred in the emulated program, which is not > uncommon and useful during target debugging. The simulator has not > encountered any error. if the sim isn't stopping, i don't think it's correct to display anything a= t=20 all. it is valid to simulate code that purposefully makes bad/weird memory= =20 accesses and then recover at runtime using signal handlers. uncommon perha= ps,=20 but not invalid. for diagnostic info meant for the developer, putting it behind a debug/trac= e=20 knob would make more sense. -mike --17/8oYur5Y32USnW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVAiwDAAoJEEFjO5/oN/WBJEkP/RnSkYgdL9uqM/Mxr1R149Hl wk5L7B2SURmzbJyGOUwn0toSmECjnVEHYIuVQCLBeiT9jkENq9gWAgCXwIkvSsgI iFG/Bk/VenKoadLM1XiOs8kkwopwpxz1p9NJGyUknyKNoNqTFbuwdYOv56qFvmTI GspDYeDRf+ura4duVUhy2ShsoKT8CpR6F1eSfHvjH2Ldhhypv00olSenThkUuVtz 5fbrZ8sWBpu9Uf0hqdEukbjDlxIwIP1GBlSRm9/BQR77LWZfXmfSVKGDx9mvx8Lg Q4nEJvs34Vq/9WRz64rQJS+WvJlzctADcVlo/mxTR83icKOEDolwCbK42nyjPvOF GKc9ow3brjEwjw3rNh5Le4rjKhjGLCFt2VAi+vUo0foiWs1Y6sqH1Mf/uKKRD3Pk RYpcIkZJh0Z88RrnOFr8BnCIYTjk1CKcFNa++pBP9LX/FZqymHcR5trnkWPHdqwQ qQ22AvbLGdCVchKbPEcrEsGshCk863BQrrQEThO7ZgNtnkoRQPxC4UIvz8IVbsku 7AX5s8phlFZ8HNk3TcPl1kDqS/xZx5yOr2iLUePHq6RrQS3ut12fetTyZbPe38uo Gbj6o/ScSayfitN9X2isbNC6IEs3Bdg4w+b9HnKVxwn3oURX/DRiFq8kOmZb0EMx +FiMitMpDiUAQ4xfcIN0 =ug3j -----END PGP SIGNATURE----- --17/8oYur5Y32USnW--