You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updates MRI core to version 1.1-20200506-0.
Added Platform_RtosSetThreadState() API to allow GDB to freeze
threads other than the one currently being single stepped via the
"set scheduler-locking step" command. The MRI core will only use
this new function if Platform_RtosIsSetThreadStateSupported()
return a non-zero value. Otherwise single stepping will silently
ignore an attempt to single step any thread other than the one
which caused the current halt and whether other threads are resumed
while single stepping is determined by the port implementor (usually
they would be resumed as that is the default behaviour expected by
GDB).
I moved alot of the thread tracking functionality of ThreadDebug into
the newly created ThreadList structure. It tracks the thread ids of the
active threads, their original priorities before being lowered to
osPriorityIdle to halt them during debugging, and their frozen/thawed/
single-stepping state. It ping pongs between g_pCurrThreadList and
g_pPrevThreadList so that it can reference the previously known
priority levels as the current priorities might still be those set by
the debugger if GDB requested that they be left frozen while single
stepping another thread.
I moved the call to restoreRtxHandlers() down into the DebugMon handler
before it attempts to awaken mriMain() rather than doing it in
mriMain() just after it awakens. This fixed an infinite loop that could
occur during certain single stepping operations:
* Single step debug event doesn't occur because that particular thread
isn't scheduled by the RTOS.
* CTRL+C is pressed by the user to force a break.
* Communication channel see the CTRL+C and pends a DebugMon interrupt.
* DebugMon interrupt attempts to wake up mriMain() by signalling the
MRI_THREAD_DEBUG_EVENT_FLAG flag. This will cause RTX to PendSV.
* When DebugMon handler returns, PendSV handler will execute in an
attempt to switch the current context over to mriMain thread. This
handler is hooked though for single stepping by ThreadDebug which
means that it will pend a DebugMon interrupt again and so enters the
infinite loop.
With my new fix, the PendSv hook is removed before DebugMon returns so
that the PendSv handler can run without pending yet another interrupt
into DebugMon.
The mriThreadSingleStepThreadId global is now set by
Platform_RtosSetThreadState() when the MRI core sets the state of a
thread to MRI_PLATFORM_THREAD_SINGLE_STEPPING. This allows GDB to
single step a thread other than the one which originally caused the
halt.
I updated Platform_RtosGetExtraThreadInfo() and
Platform_RtosGetThreadContext() in ThreadDebug to return NULL if the
specified thread-id isn't in the current g_pCurrThreadList. This fixes
a memory fault that was being generated by ThreadDebug when GDB would
first connect. When GDB first connects its sends a Hg0 command which
resulted in a call to Platform_RtosGetThreadContext() with a thread-id
of 0. The previous code would start trying to build up a register
context based off of this NULL pointer which was a bad thing.
I updated mriDebugException() to replay the calls to
Platform_RtosSetThreadState() before it makes an early exit for
situations like PC still being in the specified range during a ranged
single step operation. This allows ThreadDebug to make sure that its
g_pCurrThreadList object is always updated to the correct state before
it allows execution of the debuggee to continue.
I modified the behaviour of ranged single step to only skip the first
hardcoded breakpoint in the range whereas before it would skip all
breakpoints that were found within the range.
Now returns an error if GDB specifies more than one single step or more
than one continue action in a single vCont command. This assumption
makes the implementation of the vCont command much simpler and matches
the behaviour that I have seen from GDB so far.
0 commit comments