Chained multi core debug problem

[salfe]

I am able to use chained configuration to debug multi core MCU, but i want to have two core PAUSE/CONTINUE synchronize, so i configured the CTI and then the two core can PAUSE/CONTINUE at the same time successfully, but the problems are:

Problem1:
when two debug session run to the entry point,
then i click CONTINUE for the parent debug session, two cores runs immediately, but the debug toolbar of children session still in PAUSE status, i expect it should changed to CONTINUE automatically.

Problem2:
I clicked CONTINUE in debug toolbar for two debug session manually firstly.
then i click PAUSE for the parent debug session, the two cores halt immediately, according to the behavior of Problem1, i expect the debug toolbar of children session still in CONTINUE, but it is PAUSE actually automatically,
i have no idea why.

Problem3:
when two debug session run to the entry point,
then i click CONTINUE for the parent debug session, the debug toolbar of children session still in PAUSE status,
the two cores run immediately.
Then i click PAUSE for the parent debug session, two cores halt, but the live watch view of children not up to date, still keep the initial status.

Looking forward for your reply.

[salfe]

I did some investigate in the source code of cortex-debug,
and try to modify the code as below, then the two core can CONTINUE/HALT without CTT and also the debug toolbar of two debug sessions
can it be a feature add to cortext-debug?

[haneefdm]

What we have may not be ideal for you but it is working the way it was designed and implemented. There are many scenarios to consider.

• The stopping at entry point is nothing special. Not all cores may even have this feature enabled. We cant assume anything about this. Program execution could have stopped at other places as well (or not at all) due to many (intentional) reasons.
• Each core is running a separate program and is being debugged by parallel instance of the debugger. They are nowhere near lockstep. It is almost like using two instances of VSCode. The multiple programs are very closely coupled.
• Continue is not the only way to continue and what people do with it. Technically, step-In/Out/Over/Go-to-line are all variations of continue. Many things can/will go wrong when we try to make stuff synchronized.
• This is also how other debuggers (including VSCode) work for debugging multiple programs. These features is what we take advantage of to implement multi-core debug in VSCode
• Note that the multu-core is a misnomer, you can also do a multi-chip/multi-board debugging.

The broadcastDFS does not provide any guarantees and was never meant to synchronize things. It is used only in extreme circumstances (terminating/restarting sessions) Maybe we should not have done it for restarts. Again, we were trying to emulate what other debuggers do. This may not succeed.

Then i click PAUSE for the parent debug session, two cores halt, but the live watch view of children not up to date, still keep the initial status.

Maybe a totally different issue. The question is which context is liveWatch looking at? Need more details. Like I said, the sessions are so loosely coupled that individual windows don't even know about then and simply react to events they get -- and maybe an event is not being triggered of has the wrong information.

About the debug toolbar not showing actual status -- not sure what this is all about. We don't update the debug toolbar -- VSCode does and it relies on status reported but the various sessions. There are also multiple debug toolbars. One that is global and one that is in the Stack Window. The ones in the Stack Window represents state more accurately. I forgot how the Global one updates and what it represents in a multi-session scenario. I thing it reflects the last stopped session.