Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 220.127.116.11
peerst at gmail.com
Wed Dec 6 11:04:10 CST 2006
On 12/5/06, Kim Barrett <kab at irobot.com> wrote:
> Some further web
> searches turned up the "may_alias" type attribute. I think that attribute
> would solve the rtems chain problem, without the nasty (and I think not
> actually portable in general) union approach.
That sounds for me a very intersting feature for a transition period.
that might still cause trouble is declared with __attribute__ ((may_alias))
strict-aliasing could be turned on again without having to rewrite the whole
Then the data structures could be cleaned up one by one.
And this approach would also be save for inlined stuff in contrast to
a file by file specification in some Makefile machinery.
For ease of reference here the explanation out of gcc-4.1.0 manual:
Accesses to objects with types with this attribute are not
subjected to type-based alias analysis, but are instead assumed to
be able to alias any other type of objects, just like the `char'
type. See `-fstrict-aliasing' for more information on aliasing
Example of use:
typedef short __attribute__((__may_alias__)) short_a;
int a = 0x12345678;
short_a *b = (short_a *) &a;
b = 0;
if (a == 0x12345678)
If you replaced `short_a' with `short' in the variable
declaration, the above program would abort when compiled with
`-fstrict-aliasing', which is on by default at `-O2' or above in
recent GCC versions.
More information about the rtems-users