From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108134 invoked by alias); 7 Jun 2017 06:19:17 -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 108107 invoked by uid 89); 7 Jun 2017 06:19:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*x:5.0 X-HELO: sonic306-21.consmr.mail.ir2.yahoo.com Received: from sonic306-21.consmr.mail.ir2.yahoo.com (HELO sonic306-21.consmr.mail.ir2.yahoo.com) (77.238.176.207) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jun 2017 06:19:14 +0000 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Wed, 7 Jun 2017 06:19:16 +0000 Date: Wed, 07 Jun 2017 06:19:00 -0000 From: "Andrea Corallo via gdb-patches" Reply-To: Andrea Corallo Reply-To: Andrea Corallo To: "gdb-patches@sourceware.org" Message-ID: <486877990.6234663.1496816355818@mail.yahoo.com> In-Reply-To: <5416db91-3a90-7f4a-c901-97921aab1f9c@yahoo.it> References: <295196608.1570236.1496487588855.ref@mail.yahoo.com> <295196608.1570236.1496487588855@mail.yahoo.com> <59330B7F.90802@eagerm.com> <5416db91-3a90-7f4a-c901-97921aab1f9c@yahoo.it> Subject: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00160.txt.bz2 Any commnet on this? Best Andrea Il Domenica 4 Giugno 2017 10:14, Andrea Corallo h= a scritto: Ok understand. I think the best solution for now would be to apply this one here. In the simulator we stop executing just when we find a brki rD, 0x18 as=20 the manual says, all other brk instructions are normal sw breakpoints=20 and are gonna be executed. But we still want to check against any software breakpoint in the=20 delayed slot cause is bad anyway. The next step will be to let gdb insert brki r0, 0x18 instead of brki=20 r14, 96 when running on the simulator. Does all this make sense? I understand the sim was not developed since a while, anyway if=20 appreciated I can put some effort to try to put it in a working state=20 again. I'll have some more question but I guess is better to go step by=20 step. Best Andrea sim/microblaze/ChangeLog: 2017-06-04 Andrea Corallo * interp.c (sim_engine_run): breakpoint check condition fix. --- sim/microblaze/interp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sim/microblaze/interp.c b/sim/microblaze/interp.c index 75fc98b..48cc8cb 100644 --- a/sim/microblaze/interp.c +++ b/sim/microblaze/interp.c @@ -161,8 +161,8 @@ sim_engine_run (SIM_DESC sd, oldpc =3D PC; delay_slot_enable =3D 0; branch_taken =3D 0; - if (op =3D=3D microblaze_brk) - sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP); + if (op =3D=3D brki && IMM =3D=3D 0x18) + sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped,=20 SIM_SIGTRAP); else if (inst =3D=3D MICROBLAZE_HALT_INST) { insts +=3D 1; @@ -228,7 +228,7 @@ sim_engine_run (SIM_DESC sd, rb =3D GET_RB; ra =3D GET_RA; /* immword =3D IMM_W; */ - if (op =3D=3D microblaze_brk) + if (op =3D=3D microblaze_brk || op =3D=3D brki) { if (STATE_VERBOSE_P (sd)) fprintf (stderr, "Breakpoint set in delay slot " On 03/06/2017 21:18, Michael Eager wrote: > On 06/03/2017 03:59 AM, Andrea Corallo via gdb-patches wrote: >> I have couple of questions related to microblaze debugging and its=20 >> simulator: > > I can help with questions about MicroBlaze GDB, but can't say much=20 > about the simulator. I looked at it briefly a long time, but most of=20 > my debugging was on a development board. > > I don't believe that there has been any development on the MB sim for=20 > many years. The QEMU simulator is much more up to date. > >> When gdb add a breakpoint writes to memory the following word=20 >> 0xb9cc0060, this is defined in gdb/microblaze-tdep.h:120 >> >> /* MICROBLAZE_BREAKPOINT defines the breakpoint that should be used. >> Only used for native debugging. */ >> #define MICROBLAZE_BREAKPOINT {0xb9, 0xcc, 0x00, 0x60} >> >> This brki instruction cause the cpu to jump to 0x60 >> I guess this is because there is supposed to start a monitor program=20 >> in some configuration correct? >> Because the simulator is not expecting any monitor program wouldn't=20 >> be more appropriate to use hardware breakpoints instead? > > There is a note in the MicroBlaze Processor Reference Guide about the=20 > use of "brk" and "brki" instructions: > > As a special case, when C_USE_DEBUG is set, and =E2=80=9Cbrki rD, 0x18= =E2=80=9D is=20 > executed, a > software breakpoint is signaled to the Xilinx Microprocesor=20 > Debugger (XMD) tool, > irrespective of the value of C_BASE_VECTORS. > > (XMD is the JTAG pod used to debug using the GDB remote protocol.) > > Sim should do the something similar to this when running under GDB. > >> The other question is: the simulator is checking against the presence=20 >> of a brk instruction but not brki making gdb not stopping on the=20 >> breakpoint just inserted. >> Would make sense to check against both as in the following patch? >> >> sim/microblaze/ChangeLog: >> 2017-06-01 Andrea Corallo >> >> * interp.c (sim_engine_run): check also for breakpoint instruction brki. >> --- >> sim/microblaze/interp.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/sim/microblaze/interp.c b/sim/microblaze/interp.c >> index 75fc98b..d094a69 100644 >> --- a/sim/microblaze/interp.c >> +++ b/sim/microblaze/interp.c >> @@ -161,7 +161,7 @@ sim_engine_run (SIM_DESC sd, >> oldpc =3D PC; >> delay_slot_enable =3D 0; >> branch_taken =3D 0; >> - if (op =3D=3D microblaze_brk) >> + if (op =3D=3D microblaze_brk || op =3D=3D brki) >> sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP); >> else if (inst =3D=3D MICROBLAZE_HALT_INST) >> { > > There is another use of microblaze_brk where a check is made whether a=20 > "brk" instruction is being inserted in a delay slot. I believe that=20 > this should also be updated to also check for a "brki" instruction. >