Re: [Openocd-development] Unable to step through code in GDB
Nived schrieb: > Hi, > > i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set > a break point and then transfer control to that point. When i do a > continue (c) or a next (n) the execution returns to the same point. > > Is there any particular reason why this may be happening ? This happens to me (on Cortex M3 / LPC1768) when I have Interrupts on, e.g. Timer. The Timer keeps running when the core is halted; When you hit "continue" it will first execute the interrupt vector and then returns to the instruction that has the breakpoint set, thus hitting it again. I can see this when I use the "step" command instead of "next". You might try switching off interrupts for code stepping. There is a "cortex_m3 maskisr on|off" command for Cortex M3 MCUs, I suspect there is something similar for other ARM CPUs. Hint: GDB can exectue scripts on stepping on/off. -- J.Fischer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Mike,
Yes, it turns out i was using an older version of OpenOCD, i just tried with
the latest version, and its working fine.
Thanks so much for your help.
Drasko,
i am sorry i can't be of more help with your issue, i hope you find a
solution soon.
- Nived
On Wed, Sep 15, 2010 at 11:56 AM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC
> wrote:
> > On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn wrote:
> >> On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
> >>
> >> I sent in a patch a while back to fix this very problem on the xscale;
> i.e.,
> >> software breakpoints didn't work because of cache issues. The problem
> was
> >> clear: execution failed to halt on software breakpoints most of the
> time. And
> >> always if set a few instructions ahead of the current value of the pc.
> Once the
> >> code to clean and flush the cache was added, the problem went away and I
> haven't
> >> seen any issues since, and I use sw breakpoints frequently.
> > Yes, not hitting breakpoint can make one suspect on caches, i.e.
> > breakpoint was put in RAM, but not replicated in cache.
> > Here we are facing different behavior : breakpoint is always hit, no
> > mater at which instruction it is put.
>
> OK, writing previous e-mail, one thing crossed my mind : I was (and
> probably NIved also) putting breakppoints before starting a program,
> which in my case is e-Cos application.
> As e-Cos will initialize caches during the boot, bkpt instruction
> placed by the GDB in RAM will be replicated to the cache. But I never
> before did try to start e-Cos, stop it via GDB and place a SW
> breakpoint. This way, if it is really a cache problem, bkpt
> instruction will be placed in memory, but not replicated in cache and
> thus never seen when we do 'c'. And that is exactly what happens in my
> case - program never stops after.
>
> So, this can prove two things :
> 1) Problem comes from cache inconsistency.
> 2) My routines for cache flushing :
>
> printf ("Invalidate I$\n");
> retval = arm966e_write_cp15(target, 0x0f, 0);
>
> printf ("Invalidate D$\n");
> retval = arm966e_write_cp15(target, 0x0e, 0);
>
> are not good.
>
> My question is here can anybody, based on ARM946E doc given here :
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html
> can give me valid parameters to write into CP15 with
> arm966e_write_cp15() function in order to flush I$, because I can not
> see what is wrong with the lines I came up with...
>
>
> Nived,
> as Mike pointed out you probably took old code without cache-handling
> patch.
>
> Can you also try to run your program without any breakpoint set, than
> stop it with CTRL+C, and then set breakpoint to some instruction that
> is after the address at which you stopped (yet to come in program
> execution flow), and continue execution (by putting 'c' in GDB). If it
> is a cache problem it will never stop on this new breakpoint.
>
> Best regards,
> Drasko
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC
wrote:
> On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn wrote:
>> On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
>>
>> I sent in a patch a while back to fix this very problem on the xscale; i.e.,
>> software breakpoints didn't work because of cache issues. The problem was
>> clear: execution failed to halt on software breakpoints most of the time.
>> And
>> always if set a few instructions ahead of the current value of the pc. Once
>> the
>> code to clean and flush the cache was added, the problem went away and I
>> haven't
>> seen any issues since, and I use sw breakpoints frequently.
> Yes, not hitting breakpoint can make one suspect on caches, i.e.
> breakpoint was put in RAM, but not replicated in cache.
> Here we are facing different behavior : breakpoint is always hit, no
> mater at which instruction it is put.
OK, writing previous e-mail, one thing crossed my mind : I was (and
probably NIved also) putting breakppoints before starting a program,
which in my case is e-Cos application.
As e-Cos will initialize caches during the boot, bkpt instruction
placed by the GDB in RAM will be replicated to the cache. But I never
before did try to start e-Cos, stop it via GDB and place a SW
breakpoint. This way, if it is really a cache problem, bkpt
instruction will be placed in memory, but not replicated in cache and
thus never seen when we do 'c'. And that is exactly what happens in my
case - program never stops after.
So, this can prove two things :
1) Problem comes from cache inconsistency.
2) My routines for cache flushing :
printf ("Invalidate I$\n");
retval = arm966e_write_cp15(target, 0x0f, 0);
printf ("Invalidate D$\n");
retval = arm966e_write_cp15(target, 0x0e, 0);
are not good.
My question is here can anybody, based on ARM946E doc given here :
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html
can give me valid parameters to write into CP15 with
arm966e_write_cp15() function in order to flush I$, because I can not
see what is wrong with the lines I came up with...
Nived,
as Mike pointed out you probably took old code without cache-handling patch.
Can you also try to run your program without any breakpoint set, than
stop it with CTRL+C, and then set breakpoint to some instruction that
is after the address at which you stopped (yet to come in program
execution flow), and continue execution (by putting 'c' in GDB). If it
is a cache problem it will never stop on this new breakpoint.
Best regards,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn wrote: > On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: > > I sent in a patch a while back to fix this very problem on the xscale; i.e., > software breakpoints didn't work because of cache issues. The problem was > clear: execution failed to halt on software breakpoints most of the time. And > always if set a few instructions ahead of the current value of the pc. Once > the > code to clean and flush the cache was added, the problem went away and I > haven't > seen any issues since, and I use sw breakpoints frequently. Yes, not hitting breakpoint can make one suspect on caches, i.e. breakpoint was put in RAM, but not replicated in cache. Here we are facing different behavior : breakpoint is always hit, no mater at which instruction it is put. > > My guess is that this is not a cache issue. I never saw wierd behavior like > winding up at the same instruction after a step. If I were seeing the same > problem on my target, I would guess a bug in the single-stepping code. I am thinking the same - not a cache issue, but breakpoint management/single stepping bug. I also said that it might have something to do with interrupt handling, having in mind of SIGINT involved in a SW breakpoint mechanism... Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/15/2010 08:35 AM, Nived wrote: > Mike, > > Yes, the intelmote2 is Xscale. Could it be a configuration issue then ? Perhaps. > I am using the default cfg files pxa270.cfg, crossbow_tech_imote2.cfg and > olimex_arm_usb_tiny_h.cfg. > > I'm using the same Olimex i/f as you (finally upgraded from parallel port wiggler). My "board" is a actually a Palm Treo with JTAG wires soldered on. So only our target boards differ, and possibly our version of OpenOCD. Nived, I would make sure I'm running with the latest OpenOCD source from git, if you haven't already. Software breakpoints on xscale were fixed in the not too distant past, and breakpoiint-related enhancements just went in the other day. The latest change will let you see the bkpt instruction in memory (using 'mdw' or 'arm disassemble') right after issuing the 'bp' command. I would also experiment on the telnet interface. If after hitting the bp, if you remove it, then set another one on the next instruction and resume, do you step to the next instruction? Can you see the bkpt instruction in memory after adding it? Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: > > > If somebody can confirm this, than we can sign-off cache coherency as > a problem and concentrate on a breakpoint handling. > I sent in a patch a while back to fix this very problem on the xscale; i.e., software breakpoints didn't work because of cache issues. The problem was clear: execution failed to halt on software breakpoints most of the time. And always if set a few instructions ahead of the current value of the pc. Once the code to clean and flush the cache was added, the problem went away and I haven't seen any issues since, and I use sw breakpoints frequently. My guess is that this is not a cache issue. I never saw wierd behavior like winding up at the same instruction after a step. If I were seeing the same problem on my target, I would guess a bug in the single-stepping code. Since I'm not seeing it, I'm at a loss. Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Hi Mike,
On Wed, Sep 15, 2010 at 5:23 PM, Mike Dunn wrote:
> This is odd. I am using OpenOCD on a pxa270 target and I don't see this,
> neither through telnet nor gdb. Assumed this was a cache-related problem on
> arm946.
Might be... But I introduced cache-flushing on memory write in OPenOCD
code, as I explained before, and the problem persist.
Can somebody confirm that this :
https://lists.berlios.de/pipermail/openocd-development/2010-September/016401.html
is a correct procedure to flush the caches (I am using arm966e as a
target, but have arm946e core in my chip), i.e.
based on information given here :
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html
would these lines :
printf ("Invalidate I$\n");
retval = arm966e_write_cp15(target, 0x0f, 0);
printf ("Invalidate D$\n");
retval = arm966e_write_cp15(target, 0x0e, 0);
really flush the cache ?
If somebody can confirm this, than we can sign-off cache coherency as
a problem and concentrate on a breakpoint handling.
>
> Drasko, I looked at breakpoint management recently. It's not that arcane,
> though the call stack is a bit long; mostly wrapper functions:
>
> handle_bp_command() -> handle_bp_command_set() -> breakpoint_add() ->
> target_add_breakpoint()
> -> _add_breakpoint -> _set_breakpoint()
>
> Most of the infrastructure code is in breakpoint_add(), which allocates and
> populates a structure to record the breakpoint, and of course
> _set_breakpoint().
Thanks Mike,
I will have a look at this.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Mike, Yes, the intelmote2 is Xscale. Could it be a configuration issue then ? I am using the default cfg files pxa270.cfg, crossbow_tech_imote2.cfg and olimex_arm_usb_tiny_h.cfg. Drasko, Yes hardware breakpoints are working in my case, so it looks like the same issue you are facing. - Nived On Wed, Sep 15, 2010 at 11:23 AM, Mike Dunn wrote: > On 09/14/2010 01:45 PM, Drasko DRASKOVIC wrote: > > On Tue, Sep 14, 2010 at 10:24 PM, Nived wrote: > >> Hi, > >> i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set > a > >> break point and then transfer control to that point. When i do a > continue > >> (c) or a next (n) the execution returns to the same point. > >> Is there any particular reason why this may be happening ? > >> - Nived > > Hello Nived, > > I am experiencing the similar problem. I have been struggling for days > > with it and still have not found a solution, because it seems not to > > be too much explanation how the OpenOCD manages breakpoints > > internally. > > > This is odd. I am using OpenOCD on a pxa270 target and I don't see this, > neither through telnet nor gdb. Assumed this was a cache-related problem > on > arm946. Nived, intelmote2 is xscale also, correct? > > Drasko, I looked at breakpoint management recently. It's not that arcane, > though the call stack is a bit long; mostly wrapper functions: > > handle_bp_command() -> handle_bp_command_set() -> breakpoint_add() -> > target_add_breakpoint() >-> _add_breakpoint -> _set_breakpoint() > > Most of the infrastructure code is in breakpoint_add(), which allocates and > populates a structure to record the breakpoint, and of course > _set_breakpoint(). > > Mike > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/14/2010 01:45 PM, Drasko DRASKOVIC wrote: > On Tue, Sep 14, 2010 at 10:24 PM, Nived wrote: >> Hi, >> i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set a >> break point and then transfer control to that point. When i do a continue >> (c) or a next (n) the execution returns to the same point. >> Is there any particular reason why this may be happening ? >> - Nived > Hello Nived, > I am experiencing the similar problem. I have been struggling for days > with it and still have not found a solution, because it seems not to > be too much explanation how the OpenOCD manages breakpoints > internally. > This is odd. I am using OpenOCD on a pxa270 target and I don't see this, neither through telnet nor gdb. Assumed this was a cache-related problem on arm946. Nived, intelmote2 is xscale also, correct? Drasko, I looked at breakpoint management recently. It's not that arcane, though the call stack is a bit long; mostly wrapper functions: handle_bp_command() -> handle_bp_command_set() -> breakpoint_add() -> target_add_breakpoint() -> _add_breakpoint -> _set_breakpoint() Most of the infrastructure code is in breakpoint_add(), which allocates and populates a structure to record the breakpoint, and of course _set_breakpoint(). Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Wed, Sep 15, 2010 at 12:22 AM, Nived wrote:
> Hi,
> I have been using software breakpoints to debug, i was using an older
> version of OpenOCD and only recently upgraded to a higher version. I can
> confirm that the issue exists for software breakpoints, how do i check the
> hardware breakpoints ?
Google for the differences.
Basically, when you set SW ("normal", the one GDB sets by default)
breakpoint, GDB will temporarely replace instruction at that memory
address in RAM with special bkpt instruction (architecture dependent)
and save somewhere original instruction so it can restore it lately
(when you delete breakpoint).
HW breakpoints work, well, with the hardware support. That is, if your
core supports them. No instruction is replaced in RAM, but HW is
issuing break when observed memory location is addressed. They are
more powerful, but limited in number. For example, I have them 2 for
ARM946E.
To set a HW breakpoint in GDB insted of "break" use hbreak, like this :
(gdb) hbreak
Read a help :
(gdb) help hbreak
> Also i tried setting pc to a higher value, but it says there is no such
> variable pc when i try setting it. Could you please explain how to do this
> in a little more detail ?.
PC is a program counter register. Variables in GDB should be prefixed
by dollar sign. It is $pc for me, but observe your registers with :
(gdb) info registers
and see, maybe it is called differently for your architecture (though I doubt).
> Does deleting the break point after it hits work for you?
When I delete I can see that breakpoint instruction is replaced back
in memory by original instruction. I suspect that it is not replaced
in I$, because that part of the code is not implemented in OpenOCD for
my core. But I flushed I$, so we can pretend that it is well replaced.
But all of this does not prevent program to hit the same breakpoint on
every 'n' or 'c'. So, the problem persist.
As I explained before, we should be able to do 'n' or 'c' without
deleting breakpoint, so I would put a side I$ coherency for the
moment. I'd say that problem is somewhere else - probably in a way
that OpenOCD handles the SW interrupts provoked by the breakpoints.
Try with HW breakpoints, and report what you saw.
Also, it would be good if you can try the telnet OpenOCD monitor, so
that we confirm that the same problem happens there, and that it is
not a buggy GDB. I already tried and noted the same behavior as with
GDB, so I can say with high probability that this is a bug in OpenOCD.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Hi, I have been using software breakpoints to debug, i was using an older version of OpenOCD and only recently upgraded to a higher version. I can confirm that the issue exists for software breakpoints, how do i check the hardware breakpoints ? Also i tried setting pc to a higher value, but it says there is no such variable pc when i try setting it. Could you please explain how to do this in a little more detail ?. I know this may not be effective but just want to make sure i can go beyond this point. Does deleting the break point after it hits work for you? Thanks Nived On Tue, Sep 14, 2010 at 5:59 PM, Drasko DRASKOVIC < drasko.drasko...@gmail.com> wrote: > On Tue, Sep 14, 2010 at 11:42 PM, Nived wrote: > > Hi, > > I was just about to try the patch in sparkfun. > > Try it, maybe it will work for you. And might throw some light on the > issue. > > > Btw, in one of the mails in > > the thread you mention that you used set $pc = $pc + 4 and it worked. > Where > > did you use it and why isn't that a work around ? > > Well, when you receive SIGINT on a break point, and keep receiving it > with every next step, you can try to force your $pc over the > "breakpoint" which replaced your instruction in the memory. I picked a > number of 4 bytes, supposing that the replacing instruction will take > a 4 bytes. But it can take 2 bytes (for example of ARM thumb mode). > You can not know, so you might be forcing your $pc over some important > instruction and so never executing them, probably leading to a crash > or wrong behavior. > > I would not call this a "workaround". I just tried it to prove if > there is a trailing bkpt instruction that rests in the I$, because I > have no means to inspect cache contents at this point. I observed > memory by dumping it and I can clearly see that original instruction > is replaced correctly by GDB on deleting breakpoint. > > However, it is still a misery to me. You do not have to delete > breakpoint to step over it. Most of the time you would like to leave > it there, so it can be hit in the next pass. Why does it keep > receiving SIGINT over and over I have no idea, and I am seriously > suspecting wrong interrupt handling, but I still did not get any > confirmation on this from OpenOCD experts, nor did anyone pointed me > to the SW breakpoint handling routines in OpenOCD, so I can > investigate further. > > Just to make it clear, for me HW breakpoints work OK, as they do not > use same mechanism as SW breakpoints do. Do you confirm tat it is the > same for you ? > > Best regards, > Drasko > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Tue, Sep 14, 2010 at 11:42 PM, Nived wrote: > Hi, > I was just about to try the patch in sparkfun. Try it, maybe it will work for you. And might throw some light on the issue. > Btw, in one of the mails in > the thread you mention that you used set $pc = $pc + 4 and it worked. Where > did you use it and why isn't that a work around ? Well, when you receive SIGINT on a break point, and keep receiving it with every next step, you can try to force your $pc over the "breakpoint" which replaced your instruction in the memory. I picked a number of 4 bytes, supposing that the replacing instruction will take a 4 bytes. But it can take 2 bytes (for example of ARM thumb mode). You can not know, so you might be forcing your $pc over some important instruction and so never executing them, probably leading to a crash or wrong behavior. I would not call this a "workaround". I just tried it to prove if there is a trailing bkpt instruction that rests in the I$, because I have no means to inspect cache contents at this point. I observed memory by dumping it and I can clearly see that original instruction is replaced correctly by GDB on deleting breakpoint. However, it is still a misery to me. You do not have to delete breakpoint to step over it. Most of the time you would like to leave it there, so it can be hit in the next pass. Why does it keep receiving SIGINT over and over I have no idea, and I am seriously suspecting wrong interrupt handling, but I still did not get any confirmation on this from OpenOCD experts, nor did anyone pointed me to the SW breakpoint handling routines in OpenOCD, so I can investigate further. Just to make it clear, for me HW breakpoints work OK, as they do not use same mechanism as SW breakpoints do. Do you confirm tat it is the same for you ? Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Hi, I was just about to try the patch in sparkfun. Btw, in one of the mails in the thread you mention that you used set $pc = $pc + 4 and it worked. Where did you use it and why isn't that a work around ? - Nived On Tue, Sep 14, 2010 at 4:45 PM, Drasko DRASKOVIC < drasko.drasko...@gmail.com> wrote: > On Tue, Sep 14, 2010 at 10:24 PM, Nived wrote: > > Hi, > > i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set > a > > break point and then transfer control to that point. When i do a continue > > (c) or a next (n) the execution returns to the same point. > > Is there any particular reason why this may be happening ? > > - Nived > > Hello Nived, > I am experiencing the similar problem. I have been struggling for days > with it and still have not found a solution, because it seems not to > be too much explanation how the OpenOCD manages breakpoints > internally. > > Please take a look at this thread : > > https://lists.berlios.de/pipermail/openocd-development/2010-September/016374.html > > Do you experience the problem in OpenOCD manager via telnet (because I do) > ? > > Any information in the case of your progress on the problem will be > highly appreciated. > > Best regards, > Drasko > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Tue, Sep 14, 2010 at 10:24 PM, Nived wrote: > Hi, > i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set a > break point and then transfer control to that point. When i do a continue > (c) or a next (n) the execution returns to the same point. > Is there any particular reason why this may be happening ? > - Nived Hello Nived, I am experiencing the similar problem. I have been struggling for days with it and still have not found a solution, because it seems not to be too much explanation how the OpenOCD manages breakpoints internally. Please take a look at this thread : https://lists.berlios.de/pipermail/openocd-development/2010-September/016374.html Do you experience the problem in OpenOCD manager via telnet (because I do) ? Any information in the case of your progress on the problem will be highly appreciated. Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Unable to step through code in GDB
Hi, i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set a break point and then transfer control to that point. When i do a continue (c) or a next (n) the execution returns to the same point. Is there any particular reason why this may be happening ? - Nived ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
