Hygenic tracing hooks #1085

xQueueGenericReset does not feature any tracing hooks besides the API ENTER and EXIT calls. This introduces two new tracing hooks that, in the same style as all other queue APIs, inform a tracer that a queue has been reset.

This commit adds extended versions of all queue send trace hooks (including FROM_ISR and FAILED variants) that also hygenically expose the value of xCopyPosition. This enables tracers to identify the type of queue send and therefor queue state after the operation, which was not possible without accessing scope variables before.

Adds an extended version of traceCREATE_COUNTING_SEMAPHORE that also exposes the handle of the semaphore. This provides the tracer with the initial semaphore count which is set after the call to traceQUEUE_CREATE and was not hygienically exposed without this hook.

The old traceTASK_NOTIFY_TAKE hook was always called (no matter the success or failure of the action) and did not hygienically expose enough information for the tracer to determine the state of the task notification after it has been taken. The new traceTASK_NOTIFY_TAKE_EXT hook is called only if the notification was taken successfully and hygienically expose xClearCountOnExit. The new traceTASK_NOTIFY_TAKE_FAILED hook is called if the notification could not be taken. This matches how the tracing hooks for all other APIs that attempt to receive/take a resource and my block function: First, if the task blocks, a BLOCK or BLOCKING trace hook is called. Then, either a normal or FAILED trace hook is called, indicating if the operation timed out or succeeded. Both hooks fall back on the old traceTASK_NOTIFY_TAKE, preserving its functionality for backwards compatibility.

Both xTaskGenericNotifyStateClear and ulTaskGenericNotifyValueClear did not feature any tracing hooks besides the ENTER and EXIT calls. This adds the relevant hooks to inform a tracer that the notification state/value has changed.

The previous versions of these macros did not hygienically expose what task was being notified, and how/if the notification value was notified.

The old traceTASK_NOTIFY_WAIT hook was always called (no matter the success or failure of the action) and did not hygienically expose enough information for the tracer to determine the state of the task notification after it has been taken. The new traceTASK_NOTIFY_WAIT_EXT hook is called only if the notification was taken successfully and hygienically expose ulBitsToClearOnExit. The new traceTASK_NOTIFY_WAIT_FAILED hook is called if the notification could not be taken. This matches how the tracing hooks for all other APIs that attempt to receive/take a resource and my block function: First, if the task blocks, a BLOCK or BLOCKING trace hook is called. Then, either a normal or FAILED trace hook is called, indicating if the operation timed out or succeeded. Both hooks fall back on the old traceTASK_NOTIFY_WAIT, preserving its functionality for backwards compatibility. Not that there is a very slight breaking change in this commit: traceTASK_NOTIFY_WAIT is now called after the out-var pulNotificationValue is set. Because this pointer was in an unknown/user-set state when the tracing hook was previously called, it is highly unlikely that there are any tracers that rely on this.

…OTIFICATION_INDEX hooks. This enables tracers to track both the trigger level and notification index of a stream buffer if they are changed during operation.

Adds an extended version of traceTASK_DELAY that also exposes the number of ticks to delay.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hygenic tracing hooks #1085

Hygenic tracing hooks #1085

Commits on Jun 7, 2024

Hygenic tracing hooks #1085

Are you sure you want to change the base?

Hygenic tracing hooks #1085

Commits on Jun 7, 2024