This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
- From: Michael Eager <eager at eagerm dot com>
- To: Andrea Corallo <andrea_corallo at yahoo dot it>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Sat, 3 Jun 2017 12:18:23 -0700
- Subject: Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
- Authentication-results: sourceware.org; auth=none
- References: <295196608.1570236.1496487588855.ref@mail.yahoo.com> <295196608.1570236.1496487588855@mail.yahoo.com>
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.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077