Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 22.214.171.124
joel.sherrill at oarcorp.com
Wed Dec 6 17:17:21 UTC 2006
Peer Stritzinger wrote:
> 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.
> If everything
> 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;
> main (void)
> 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.
I like this since it lets us mark the places known to alias and not have to
immediately redesign them.
Would this have to placed on Chain_node_struct, Chain_Control, and
And most importantly, does it fix your known miscompilation?
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users