Incorrect C operator precedence in RTOS tasks.c?

[slcasner]

In my app I want to have a command that lists all the tasks in the system with the allocated stack size, amount of stack currently used, and the maximum stack used. I observed that uxTaskGetSystemState() does not set the pxStackBase member of the TaskStatus_t array, so I added the following hack code into prvListTaskWithinSingleList() in components/freertos/tasks.c:

Code: Select all

poison_head_t* stackblk = (poison_head_t*)(pxNextTCB->pxStack - sizeof(poison_head_t));
uint32_t stackinfo = stackblk->alloc_size << 16;
stackinfo |= pxNextTCB->pxTopOfStack - pxNextTCB->pxStack;
pxTaskStatusArray[ uxTask ].pxStackBase = (StackType_t*)stackinfo;

This should return the allocated size of the stack in the high half of the pxStackBase member and the amount of the stack currently used in the low half. However, this returns bogus values. To get the correct values I need to add parentheses to force the subtraction to happen before the assignment by OR operation:

Code: Select all

stackinfo |= (pxNextTCB->pxTopOfStack - pxNextTCB->pxStack);

According to the C precedence rules, the parentheses should not be required. In fact, I tried to replicate this at the app level using the hello_world example but the problem was not observed there. Also, this used to work correctly in release/v2.1. Is something funny going on with the new version of the tools?

p.s. It would be really nice to have some official way to get the stack information I want without having to hack the system this way.

[permal]

Sound like you're looking for uxTaskGetStackHighWaterMark()

[slcasner]

Sound like you're looking for uxTaskGetStackHighWaterMark()

I am already using that call to get the minimum unused stack space. I need my hack to get the total stack space and current stack space to go with it, and I find it more convenient to show the maximum stack used (total - minimum) in my display. If pxStackBase was actually implemented as specified that would get me part way there. I could go rummaging through TCBs from user code, but that is unsafe.

But the main point of my post was that the C operator precedence seems to be not working as specified.

[slcasner]

Nevermind. This was an illusion (as is usually the case when one suspects the compiler is misbehaving) caused by confusion between different IDF_PATH environments while testing the cases.