* [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
[not found] <295196608.1570236.1496487588855.ref@mail.yahoo.com>
@ 2017-06-03 11:00 ` Andrea Corallo via gdb-patches
2017-06-03 19:18 ` Michael Eager
0 siblings, 1 reply; 6+ messages in thread
From: Andrea Corallo via gdb-patches @ 2017-06-03 11:00 UTC (permalink / raw)
To: GDB Patches
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(-)
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)
{
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
2017-06-03 11:00 ` [PATCH] sim: microblaze: breakpoint inst check + a couple of questions Andrea Corallo via gdb-patches
@ 2017-06-03 19:18 ` Michael Eager
2017-06-04 8:14 ` Andrea Corallo via gdb-patches
0 siblings, 1 reply; 6+ messages in thread
From: Michael Eager @ 2017-06-03 19:18 UTC (permalink / raw)
To: Andrea Corallo, GDB Patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
2017-06-03 19:18 ` Michael Eager
@ 2017-06-04 8:14 ` Andrea Corallo via gdb-patches
2017-06-07 6:19 ` Andrea Corallo via gdb-patches
2017-06-07 16:54 ` Michael Eager
0 siblings, 2 replies; 6+ messages in thread
From: Andrea Corallo via gdb-patches @ 2017-06-04 8:14 UTC (permalink / raw)
To: Michael Eager, GDB Patches
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
the 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
appreciated 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<andrea_corallo@yahoo.it>
* 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 = PC;
delay_slot_enable = 0;
branch_taken = 0;
- if (op == microblaze_brk)
- sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
+ if (op == brki && IMM == 0x18)
+ sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped,
SIM_SIGTRAP);
else if (inst == MICROBLAZE_HALT_INST)
{
insts += 1;
@@ -228,7 +228,7 @@ sim_engine_run (SIM_DESC sd,
rb = GET_RB;
ra = GET_RA;
/* immword = IMM_W; */
- if (op == microblaze_brk)
+ if (op == microblaze_brk || op == 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
>> 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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
2017-06-04 8:14 ` Andrea Corallo via gdb-patches
@ 2017-06-07 6:19 ` Andrea Corallo via gdb-patches
2017-06-07 16:54 ` Michael Eager
1 sibling, 0 replies; 6+ messages in thread
From: Andrea Corallo via gdb-patches @ 2017-06-07 6:19 UTC (permalink / raw)
To: gdb-patches
Any commnet on this?
Best
Andrea
Il Domenica 4 Giugno 2017 10:14, Andrea Corallo <andrea_corallo@yahoo.it> ha 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
the 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
appreciated 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<andrea_corallo@yahoo.it>
* 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 = PC;
delay_slot_enable = 0;
branch_taken = 0;
- if (op == microblaze_brk)
- sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
+ if (op == brki && IMM == 0x18)
+ sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped,
SIM_SIGTRAP);
else if (inst == MICROBLAZE_HALT_INST)
{
insts += 1;
@@ -228,7 +228,7 @@ sim_engine_run (SIM_DESC sd,
rb = GET_RB;
ra = GET_RA;
/* immword = IMM_W; */
- if (op == microblaze_brk)
+ if (op == microblaze_brk || op == 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
>> 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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
2017-06-04 8:14 ` Andrea Corallo via gdb-patches
2017-06-07 6:19 ` Andrea Corallo via gdb-patches
@ 2017-06-07 16:54 ` Michael Eager
2021-02-01 3:04 ` Mike Frysinger
1 sibling, 1 reply; 6+ messages in thread
From: Michael Eager @ 2017-06-07 16:54 UTC (permalink / raw)
To: gdb-patches, Andrea Corallo
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 the 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 appreciated 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<andrea_corallo@yahoo.it>
>
> * 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 = PC;
> delay_slot_enable = 0;
> branch_taken = 0;
> - if (op == microblaze_brk)
> - sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
> + if (op == brki && IMM == 0x18)
> + sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
> else if (inst == MICROBLAZE_HALT_INST)
> {
> insts += 1;
> @@ -228,7 +228,7 @@ sim_engine_run (SIM_DESC sd,
> rb = GET_RB;
> ra = GET_RA;
> /* immword = IMM_W; */
> - if (op == microblaze_brk)
> + if (op == microblaze_brk || op == 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 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.
Sorry not to respond sooner.
I suggest that you create a local branch for your simulator development and make changes on that
branch. When you have the MB sim working as well as you would like. post the series of patches.
If you have questions about a change, I'll be happy to help.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] sim: microblaze: breakpoint inst check + a couple of questions
2017-06-07 16:54 ` Michael Eager
@ 2021-02-01 3:04 ` Mike Frysinger
0 siblings, 0 replies; 6+ messages in thread
From: Mike Frysinger @ 2021-02-01 3:04 UTC (permalink / raw)
To: Michael Eager; +Cc: gdb-patches, Andrea Corallo
On 07 Jun 2017 09:54, Michael Eager wrote:
> I suggest that you create a local branch for your simulator development and make changes on that
> branch. When you have the MB sim working as well as you would like. post the series of patches.
we can take incremental fixes though if we know they're correct.
-mike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-02-01 3:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <295196608.1570236.1496487588855.ref@mail.yahoo.com>
2017-06-03 11:00 ` [PATCH] sim: microblaze: breakpoint inst check + a couple of questions Andrea Corallo via gdb-patches
2017-06-03 19:18 ` Michael Eager
2017-06-04 8:14 ` Andrea Corallo via gdb-patches
2017-06-07 6:19 ` Andrea Corallo via gdb-patches
2017-06-07 16:54 ` Michael Eager
2021-02-01 3:04 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).