jphickey
commented
9 months ago Ready for [re-]review. Checking further into detail of the RTEMS implementation -- the needed API was only added in the latest development branch (6.x) and is not available on either RTEMS 4.11 nor 5.x. Furthermore, the documentation warns that this is only intended for use with low-level device drivers that have special requirements, and general tasks should not force a stack pointer, as the stack buffers have special requirements for size and alignment.
Therefore, with the consideration that we will likely also deprecate/discourage users from specifying a stack buffer due to similar issues on other platforms, the best solution for now is to simply skip this functional test on RTEMS.
Checklist (Please check before submitting)
Describe the contribution When the OS_TaskCreate() function is called with a non-NULL stack pointer, the POSIX implementation now should use this pointer as intended. Previously it was always allocating a new stack buffer, ignoring the passed-in pointer.
NOTE: When using this feature, the caller must use caution to make sure the buffer being passed in is large enough to use as a task stack. Particularly when running under a desktop Linux/Glibc environment, the infrastructure puts a considerably large object on the stack. For example, in the osal-core-tests, the stack size was too small.
Fixes #1449
Testing performed Build and run all tests. Added tests that ensure the stack pointer is being honored as expected.
Expected behavior changes User-supplied stack buffer will be used on POSIX.
System(s) tested on Debian
Additional context This could have negative consequences if the user was assuming RTOS-like behavior (e.g. no thread local storage) and was using very small stack sizes. If the supplied stack size is less than 16k, (or
PTHREAD_STACK_MIN) then the call will now fail, whereas previously it would quietly be made bigger than requested.Contributor Info - All information REQUIRED for consideration of pull request Joseph Hickey, Vantage Systems, Inc.