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
> these issues

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

> [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 (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#L3
4
> 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

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

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

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

> I made 2 quick fixes which solve my problems
> 
https://github.com/piec/openocd/commits/b91b50c3bd56783525c6039
3b282115e4bd
> 80f9d I think the stepping fix is ok.

Yes, that one 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). 

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.

> Best regards,
> Pierre

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to