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