[OpenOCD-devel] [openocd:tickets] #150 Targets in "Examine Deferred" state create issues

Discussion:

Pierre

2017-04-21 09:09:38 UTC

---

** [tickets:#150] Targets in "Examine Deferred" state create issues**

**Status:** new
**Milestone:** 0.9.0
**Created:** Fri Apr 21, 2017 09:09 AM UTC by Pierre
**Last Updated:** Fri Apr 21, 2017 09:09 AM UTC
**Owner:** nobody
**Attachments:**

- [single-stepping.txt](https://sourceforge.net/p/openocd/tickets/150/attachment/single-stepping.txt) (5.2 kB; text/plain)

Hi,

First of all thanks for making openocd, it's a great project!

I'm using the git version of openocd 0.10.0+dev-00096-gf605a23bc (cloned yesterday).
I'm targeting a Lemaker HiKey board which has a hi6220 (8 cores). If I'm correct, at reset only core 0 is powered which means that cores 1-7 can't be examined, that's why -defer-examine is used in https://github.com/ntfreak/openocd/blob/master/tcl/target/hi6220.cfg#L34

I'm debugging code in early stages of the boot when cores 1-7 aren't powered yet and thus not examined yet and having unexamined targets creates issues with openocd, for example:

* setting a breakpoint generates an error because openocd tries to do it on every target (even unexamined ones)

~~~

bp 0x10000000 4 hw

no hardware breakpoint available
can't add breakpoint: resource not available
Failure setting breakpoint, the same address(IVA) is already used

Breakpoint(IVA): 0x10000000, 0x4, 1
~~~

* single-stepping an instruction in gdb "si" generates a segfault in openocd. I'm attaching a backtrace

-----

I made 2 quick fixes which solve my problems https://github.com/piec/openocd/commits/b91b50c3bd56783525c60393b282115e4bd80f9d

I think the stepping fix is ok.
But the breakpoint commit is just a workaround, I suppose openocd should save the breakpoints to be added after defered targets are examined (later).

Best regards,
Pierre

---

Sent from sourceforge.net because openocd-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

Pierre

2017-04-21 09:59:30 UTC

Permalink

I've just noticed http://openocd.zylin.com/#/c/3999/ that be a way to avoid these issues

---

** [tickets:#150] Targets in "Examine Deferred" state create issues**

**Status:** new
**Milestone:** 0.9.0
**Created:** Fri Apr 21, 2017 09:09 AM UTC by Pierre
**Last Updated:** Fri Apr 21, 2017 09:09 AM UTC
**Owner:** nobody
**Attachments:**

- [single-stepping.txt](https://sourceforge.net/p/openocd/tickets/150/attachment/single-stepping.txt) (5.2 kB; text/plain)

Hi,

First of all thanks for making openocd, it's a great project!

I'm using the git version of openocd 0.10.0+dev-00096-gf605a23bc (cloned yesterday).
I'm targeting a Lemaker HiKey board which has a hi6220 (8 cores). If I'm correct, at reset only core 0 is powered which means that cores 1-7 can't be examined, that's why -defer-examine is used in https://github.com/ntfreak/openocd/blob/master/tcl/target/hi6220.cfg#L34

I'm debugging code in early stages of the boot when cores 1-7 aren't powered yet and thus not examined yet and having unexamined targets creates issues with openocd, for example:

* setting a breakpoint generates an error because openocd tries to do it on every target (even unexamined ones)

~~~

bp 0x10000000 4 hw

no hardware breakpoint available
can't add breakpoint: resource not available
Failure setting breakpoint, the same address(IVA) is already used

Matthias Welwarsky

2017-04-24 14:29:19 UTC

Permalink

On Friday 21 April 2017 09:59:30 Pierre wrote:> I've just noticed
http://openocd.zylin.com/#/c/3999/ that be a way to avoid

Post by Pierre
these issues

Nice to hear, but the bugs of course exist nevertheless. See comments
below.

Post by Pierre
[tickets:#150] Targets in "Examine Deferred" state create issues
Status: new
Milestone: 0.9.0
Created: Fri Apr 21, 2017 09:09 AM UTC by Pierre
Last Updated: Fri Apr 21, 2017 09:09 AM UTC
Owner: nobody
single-stepping.txt (5.2 kB; text/plain)
Hi,
First of all thanks for making openocd, it's a great project!
I'm using the git version of openocd 0.10.0+dev-00096-gf605a23bc

(cloned

Post by Pierre
yesterday). I'm targeting a Lemaker HiKey board which has a hi6220

Post by Pierre
cores). If I'm correct, at reset only core 0 is powered which means that
cores 1-7 can't be examined, that's why -defer-examine is used in

https://github.com/ntfreak/openocd/blob/master/tcl/target/hi6220.cfg#L3
4

Post by Pierre
I'm debugging code in early stages of the boot when cores 1-7 aren't
powered yet and thus not examined yet and having unexamined

targets creates

Post by Pierre
issues with openocd, for example: setting a breakpoint generates an

error

Post by Pierre
because openocd tries to do it on every target (even unexamined

ones)>

Post by Pierre

bp 0x10000000 4 hw

no hardware breakpoint available
can't add breakpoint: resource not available
Failure setting breakpoint, the same address(IVA) is already used

I've noticed that one, too, but didn't get around investigating it, thank you
for spotting and tracking it down.

Post by Pierre
single-stepping an instruction in gdb "si" generates a segfault in

openocd.

Post by Pierre
I'm attaching a backtrace

Indeed, the code tries to access an unexamined core, that is bound to
fail. Easily fixed, though.

Post by Pierre
I made 2 quick fixes which solve my problems

https://github.com/piec/openocd/commits/b91b50c3bd56783525c6039
3b282115e4bd

Post by Pierre
80f9d I think the stepping fix is ok.

Yes, that one is OK.

Post by Pierre
But the breakpoint commit is just a workaround, I suppose openocd

should

Post by Pierre
save the breakpoints to be added after defered targets are examined
(later).

I guess that's correct. Not sure how that is handled by the target layer,
but I supposed there is a list of breakpoints anyway, maybe they need
some additional flag to understand whether a breakpoint was actually
set or not, or maybe a hook needs to be added into the arp_examine
function to re-set the breakpoints once a target is examined.

Post by Pierre
Best regards,
Pierre