sim: microblaze: breakpoint inst check + a couple of questions

  I have couple of questions related to microblaze debugging and its simulator:

When gdb add a breakpoint writes to memory the following word 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 in some configuration correct?
Because the simulator is not expecting any monitor program wouldn't be more appropriate to use hardware breakpoints instead?

The other question is: the simulator is checking against the presence of 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  <andrea_corallo@yahoo.it>

* interp.c (sim_engine_run): check also for breakpoint instruction brki.
---
sim/microblaze/interp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
  

On 06/03/2017 03:59 AM, Andrea Corallo via gdb-patches wrote:
> I have couple of questions related to microblaze debugging and its simulator:

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 many years.  The QEMU 
simulator is much more up to date.

> When gdb add a breakpoint writes to memory the following word 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 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 use of "brk" and "brki" 
instructions:

    As a special case, when C_USE_DEBUG is set, and “brki rD, 0x18” 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 of 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  <andrea_corallo@yahoo.it>
>
> * 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 = PC;
> delay_slot_enable = 0;
> branch_taken = 0;
> -      if (op == microblaze_brk)
> +      if (op == microblaze_brk || op == brki)
> sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
> else if (inst == 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.