From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18971 invoked by alias); 16 Dec 2016 20:33:37 -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 18954 invoked by uid 89); 16 Dec 2016 20:33:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=dimitrov, Dimitar, dimitar, Dimitrov 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 ESMTP; Fri, 16 Dec 2016 20:33:26 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 9B03B34100F; Fri, 16 Dec 2016 20:33:24 +0000 (UTC) Date: Fri, 16 Dec 2016 20:33:00 -0000 From: Mike Frysinger To: Dimitar Dimitrov Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] PRU Simulator port Message-ID: <20161216203324.GA30602@vapier.lan> Mail-Followup-To: Dimitar Dimitrov , gdb-patches@sourceware.org References: <20161205211108.26616-1-dimitar@dinux.eu> <20161206231731.GG10558@vapier.lan> <9877120.H2PyqMF4WO@tpdeb> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <9877120.H2PyqMF4WO@tpdeb> X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00329.txt.bz2 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2843 On 09 Dec 2016 22:39, Dimitar Dimitrov wrote: > I'll change it. I assume my copyright papers for GDB will cover this simu= lator patch? i think they want sep papers. who knows! try this small form (it has directions in it): http://git.savannah.gnu.org/gitweb/?p=3Dgnulib.git;a=3Dblob_plain;f=3Ddoc/C= opyright/request-assign.future;hb=3DHEAD > > > +static inline void > > > +pru_reg2dmem (SIM_CPU *cpu, uint32_t addr, unsigned int nbytes, > > > + int regn, int regb) > > > +{ > > > + if (abort_on_dmem_zero_access && addr < 4) > > > + { > > > + sim_core_signal (CPU_STATE (cpu), cpu, PC_byteaddr, write_map, > > > + nbytes, addr, write_transfer, > > > + SIM_SIGSEGV); > > > + } > > > + else if ((addr >=3D PC_ADDR_SPACE_MARKER) > > > + || (addr + nbytes > PC_ADDR_SPACE_MARKER)) > > > + { > > > + sim_core_signal (CPU_STATE (cpu), cpu, PC_byteaddr, write_map, > > > + nbytes, addr, write_transfer, > > > + SIM_SIGSEGV); > > > + } > > > + else if ((regn * 4 + regb + nbytes) > (32 * 4)) > > > + { > > > + /* Register and load size are not valid. */ > > > + sim_core_signal (CPU_STATE (cpu), cpu, PC_byteaddr, write_map, > > > + nbytes, addr, write_transfer, > > > + SIM_SIGILL); > > > + } > >=20 > > do you really need to do all this ? seems like the existing > > sim_core_write_1 function already deals properly with writes > > to out-of-bind addresses. >=20 > I believe the checks are needed. I let sim_core_write_1 handle the Data R= AM bounds checking. On top of that, I want to: > - Ensure that instruction memory (PC_ADDR_SPACE_MARKER) is not accesse= d by the CPU data path. i don't believe this is possible today with gdb. when gdb makes a request to the sim to do things like set breakpoints and decode instructinos, it follows the same paths as the sim which means it'll break gdb :(. i wanted to do the same thing for Blackfin where there's a chunk of SRAM that can only be executed, but trying to do data reads/stores would fail. > - Check that the load/store burst length is valid (i.e. do not access = beyond the last CPU register). shouldn't this be handled by limiting the memory region addr+size ? > - Optionally catch NULL pointer dereferences. hmm, seems like this would be better as a common sim option ? but also, this runs into the same problems as i described above i think. > > > +static void > > > +pru_sim_syscall (SIM_DESC sd, SIM_CPU *cpu) > >=20 > > seems like you should use sim_syscall instead of implementing your own > > ad-hoc syscall ABI > > I'll fix libgloss to use more standard syscalls, and then I'll switch to = sim_syscall. that was going to be my next question :). if you have time, then yeah, changing all your libgloss syscall #'s to use the default ones would be best. -mike --ibTvN161/egqYuK8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYVE+UAAoJEEFjO5/oN/WBfXIP/iVZx5SahAAIQs+MFmud3x38 zwPTk7Fqnt4kqFm67UEnacjKWUPkB4zba+y5OQJHnIdSKQYiGFxEWNlrt82CuvL7 No3E7gRmQF+o12zoaEvJqDg9sn6ZzRqIGK/DD4Vnm58Ptf+fH47QN8fUeB9klh9X zGnEZyIKab22r82tsDjMLGhRljYVA11qnOt3WoGvQvgI7DmE+m2S/Q1KJgAKZ9/b nEhgWIZTKO81cm+izyDjAmjl1mClYl0crR8JQlHzBZk6hgj0i7vqZZHd+og2AsbY ewtCEBFq29USVa5WV4j+iNOfCkua2OLDdUF0aMEfEAu9L/VDfKDey29VBCxr/Ft+ +6FQ7xGbKT4D9QdUjfb9hyP4o/aeq/PcRQZmjcT/10P9kHLq6QjYRvGj383QJsqK r6ng5CdbaMFeNF/dkn4jwi1wEnhR9SBoBbpLVMxfDpZFHGltkYcL2VDtDCSpzuNZ KB20jqoRoCA/D6JOjHqOkB/Z6RdjY9l12DHWfm+HuW4QWEUA6HOONyDpb4zEUUtB 0fyW2JkWiSy3vSJTi1jgGsAk5fNfsySXKTjsY8QzwKI0GqBC4z4oe4mEiBFR4A2o ldxgp/CBE6wFP4IW0ablFhwAslZcEhyr/rvzvE1j42jKcIVLjuyDXSdRFaDSFNmq gf5VQ/+CJfsrVkxRm1Rz =W1kc -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--