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

[Thomas Doerfler]

Ralf,


Ralf Corsepius schrieb:
> On Tue, 2006-11-21 at 12:09 +0100, Peer Stritzinger wrote:
>> Fix:
>>
>> Add '-fno-strict-aliasing' to cflags when building RTEMS
> 
> Sorry, but this is a no-go. strict-aliasing is the default in GCC for a
> very long time (IIRC, since 4.0.0) and must work.

As far as I discussed this with Peer some time ago, the problem is not
GCC itself, but the way RTEMS overlays data structures Chain_Node_struct
and Chain_Control in "chain.h/chain.inl". So you are right, the proper
way to fix the problem is to fix the code.

As far as I understood the problem, the following two data structures
are used together, but GCC does not understand that they are sometimes
aliased:

struct Chain_Node_struct {
  Chain_Node *next;
  Chain_Node *previous;
};

typedef struct {
  Chain_Node *first;
  Chain_Node *permanent_null;
  Chain_Node *last;
} Chain_Control;

An example for aliased use is:

RTEMS_INLINE_ROUTINE Chain_Node *_Chain_Tail(
  Chain_Control *the_chain
)
{
   return (Chain_Node *) &the_chain->permanent_null;
}

In a code using "_Chain_Tail", there may be a (Chain_Node *) pointer and
a (Chain_Control *) pointer, both pointing to the same memory area and
both used to read/write this area.

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?

I am sure this problem MUST be solved before 4.7 goes out. The fix from
Peer may be a temporary workaround (also for the systems already running
with RTEMS starting with GCC 3.4).

Peer, can you provide us with the know-how to detect, whether GCC
generates good/bad code?

wkr,
Thomas.

> 
> If some code breaks, this code has to be considered broken and must be
> fixed. I.e. we'd have to have a concrete piece of code to be able to
> analyze and fix what might be going wrong.
> 
> Ralf
> 
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request