From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76887 invoked by alias); 7 Jun 2017 16:54:18 -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 73634 invoked by uid 89); 7 Jun 2017 16:54:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=1960, sooner, alto X-HELO: resqmta-po-10v.sys.comcast.net Received: from resqmta-po-10v.sys.comcast.net (HELO resqmta-po-10v.sys.comcast.net) (96.114.154.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jun 2017 16:54:14 +0000 Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-10v.sys.comcast.net with SMTP id IeD6dDKlQiWLuIeDpdRhkL; Wed, 07 Jun 2017 16:54:17 +0000 Received: from vm-fedora21.eagercon.com ([IPv6:2601:647:4d04:5190:20c:29ff:fe70:d3be]) by resomta-po-14v.sys.comcast.net with SMTP id IeDndnMhFWGiLIeDodQ32O; Wed, 07 Jun 2017 16:54:16 +0000 Subject: Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions To: gdb-patches@sourceware.org, Andrea Corallo 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> From: Michael Eager Message-ID: <59382FB7.6050403@eagerm.com> Date: Wed, 07 Jun 2017 16:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <5416db91-3a90-7f4a-c901-97921aab1f9c@yahoo.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfKVjfMuq/3W82Sx5Nf52Nr4NdzdZMM1ajklTshElwx3VGes6D4AoOWvwDmwbckMI5yA2x38p+fa375sg2kGn25ElQ/1anQe9no3+3Yglwh24TuJyIxWT IUzzXugOmMUYDjVKfHbV+Cov+ruH2UKN6OcUiYyKpQAwvyXQtFVy7fzGypHqpS2FE0rtMK8D7AVpjmD3+iIu0lj0aoFngOMV1OU= X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00174.txt.bz2 See below. Usual style on this mailing list is to not top post. On 06/04/2017 01:14 AM, Andrea Corallo via gdb-patches wrote: > 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 t= he manual says, all other > brk instructions are normal sw breakpoints and are gonna be executed. > > But we still want to check against any software breakpoint in the delayed= slot cause is bad anyway. > > The next step will be to let gdb insert brki r0, 0x18 instead of brki r14= , 96 when running on the > simulator. > > Does all this make sense? > > I understand the sim was not developed since a while, anyway if appreciat= ed I can put some effort to > try to put it in a working state again. I'll have some more question but = I guess is better to go > step by 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, SIM_SIGT= RAP); > 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 simu= lator: >> >> I can help with questions about MicroBlaze GDB, but can't say much about= the simulator. I looked >> at it briefly a long time, but most of my debugging was on a development= board. >> >> I don't believe that there has been any development on the MB sim for ma= ny years. The QEMU >> simulator is much more up to date. >> >>> When gdb add a breakpoint writes to memory the following word 0xb9cc006= 0, 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 in= some configuration correct? >>> Because the simulator is not expecting any monitor program wouldn't be = more appropriate to use >>> hardware breakpoints instead? >> >> There is a note in the MicroBlaze Processor Reference Guide about the us= e of "brk" and "brki" >> instructions: >> >> As a special case, when C_USE_DEBUG is set, and =E2=80=9Cbrki rD, 0x1= 8=E2=80=9D is executed, a >> software breakpoint is signaled to the Xilinx Microprocesor 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 o= f a brk instruction but >>> not brki making gdb not stopping on the 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 "= brk" instruction is being >> inserted in a delay slot. I believe that this should also be updated to= also check for a "brki" >> instruction. Sorry not to respond sooner. I suggest that you create a local branch for your simulator development and= make changes on that=20 branch. When you have the MB sim working as well as you would like. post t= he series of patches. If you have questions about a change, I'll be happy to help. --=20 Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077