Fwd: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Joel Sherrill]

Ralf Corsepius wrote:
> On Tue, 2006-11-21 at 13:38 +0100, Thomas Doerfler wrote:
>
>   
>> I found a good discussion about GCC and strict aliasing here:
>>
>> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
>>
>> Maybe it would help to modify the definition of Chain_Ctronol to
>> something like:
>>
>> typedef union {
>>   struct {
>>     struct Chain_Node_struct head;
>>     void *fill_loc1;
>>   } head_node;
>>
>>   struct {
>>     void *fill_loc1;
>>     struct Chain_Node_struct tail;
>>   } tail_node;
>> } Chain_Control;
>>
>> The names are NOT good, and surely all chain.c/chain.inl functions would
>> have to be adapted but this might be a mechanical search/replace procedure.
>>
>> Any comments to a change like this?
>>     
Using a union like this would probably remove a lot of casts and could
make the code easier to read.

I would want to be careful about the names.  And the changes do extend
a bit out of the chain code.  There are a few places which explicitly do
casts to (Chain_Node *) which could be cleaned up.

> Normally, there are easier ways out of such issues. 
>
>   
We certainly haven't had to do anything too difficult in the past to 
resolve these
types of issues.

Would making the pointers in the chain control and node control structures
be enough to avoid this?
> Esp. because GCC normally is pretty good at warning about places
> exposing this problem (the infamous "punned pointer" warnings). 
>
>   
Yes.  We had 100s of these at one point.  I am surprised there is no warning
on any target for this.  I compile the BSP Peer is using all the time.

> But we'd need an actual piece of code exposing this problem. Anything
> else is "poking around in the fog"
>   
Peer's example is cpukit/score/src/threadresettimeslice.c.

Peer .. is it possible to construct a simple executable test case that 
breaks?  It
sounds like it would be something like two tasks at the same priority 
and some
code to schedule them like this. 

Hand examining PowerPC code isn't fun.
>   
>> I am sure this problem MUST be solved before 4.7 goes out.
>>     
> ACK.
>
>   
Agreed. 

> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>