]> begriffs open source - freertos/commit
Introduce portMEMORY_BARRIER for Microblaze port. (#621)
authorbbain <16752579+bbain@users.noreply.github.com>
Mon, 13 Feb 2023 04:58:20 +0000 (15:58 +1100)
committerGitHub <noreply@github.com>
Mon, 13 Feb 2023 04:58:20 +0000 (10:28 +0530)
commit050cf0d80f4a25c06a37efa7ab6f1b4c877a84b0
tree0d6f704fb0bf34d7e55206dc4e9ebb347ab0864e
parent91c20f5f425b18b641765217586a82a62e1aa45a
Introduce portMEMORY_BARRIER for Microblaze port. (#621)

The introduction of `portMEMORY_BARRIER` will ensure
the places in the kernel use a barrier will work.
For example, `xTaskResumeAll` has a memory barrier
to ensure its correctness when compiled with optimization
enabled. Without the barrier `xTaskResumeAll` can fail
(e.g. start reading and writing to address 0 and/or
infinite looping) when `xPendingReadyList` contains more
than one task to restore.

In `xTaskResumeAll` the compiler chooses to cache the
`pxTCB` the first time through the loop for use
in every subsequent loop. This is incorrect as the
removal of `pxTCB->xEventListItem` will actually
change the value of `pxTCB` if it was read again
at the top of the loop. The barrier forces the compiler
to read `pxTCB` again at the top of the loop.

The compiler is operating correctly. The removal
`pxTCB->xEventListItem` executes on a `List_t *`
and `ListItem_t *`.  This means that the compiler
can assume that any `MiniListItem_t` values are
unchanged by the loop (i.e. "strict-aliasing").
This allows the compiler to cache `pxTCB` as it
is obtained via a `MiniListItem_t`. This is incorrect
in this case because it is possible for a `ListItem_t *`
to actually alias a `MiniListItem_t`. This is technically
a "violation of aliasing rules" so we use the the barrier
to disable the strict-aliasing optimization in this loop.
portable/GCC/MicroBlaze/portmacro.h
portable/GCC/MicroBlazeV8/portmacro.h
portable/GCC/MicroBlazeV9/portmacro.h