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 08:52 -0600, Joel Sherrill wrote:
>   
>> 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.
>>     
> It's "'em casts" which are the origin of this evil!
>   
:)  I have attached a patch which (if my grep worked) which should make 
a big
dent in this. 

+ In malloc.c, we keep a chain of pending memory to free and I added
an intermediate variable between the free'ed address being queued.

+ I don't know how to deal with the macros/routines _Chain_Head and 
_Chain_Tail
in chain.inl.

+ Chain_Initialize in chain.c has a cast of an address when building the 
chain initially
and I don't know how to deal with that.

Suggestions on the cases above to improve the attached patch and see if 
it is enough
to address Peer's problem.

>  
>   
>> 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.
>>     
> Remove these casts and eliminate the "punned warnings" without using
> explict casts. In 90% of all cases all you'll probably need to solve the
> issue is a temporary pointer.
>
> Ralf
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chain_casts_1.diff
Type: text/x-patch
Size: 5799 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20061121/88c7374f/attachment-0001.bin>