EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: C strict aliasing rules
From: Eric Norum <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: [email protected], Core talk list <[email protected]>
Date: Tue, 28 Nov 2006 14:51:55 -0600
On Nov 28, 2006, at 2:35 PM, Andrew Johnson wrote:
Eric Norum wrote:
So where's the best place to make the addition? To configure/ CONFIG.gnuCommon in the OPT....YES macros?
OPT_CFLAGS_YES = -O3 -fno-strict-aliasing
OPT_CXXFLAGS_YES = -O3 -fno-strict-aliasing

Nope:
	cc1plus: Invalid option `-fno-strict-aliasing'

That's from a vxWorks compile - this will have to be set by each architecture that uses gcc.

Have we identified *anywhere* in base yet where we actually need this though? We've been running IOCs on Linux and Solaris built with gcc 4.0.2 and -O3 for ages, and nothing has failed or even behaved strangely yet that I can remember; isn't this all a storm in a tea-cup?

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

You're right in that this doesn't appear to have caused any problems with EPICS.

Here's the RTEMS bug-tracker item that started all of this. The problem manifests itself in a rather 'clever' construct within RTEMS, but I'm not convinced that that means we should ignore the issue.

===========================================================
Category: RTEMS Core (or make_build depending on perspective)

Synopsis: Struct aliasing problem that causes Thread_Ready_chain to be corrupted

Severity: serious

Priority: medium

Class: sw-bug

Originator: Peer Stritzinger

Release: 4.6.99.3

Organization: Dipl.Phys. Peer Stritzinger GmbH

Environment:

   Host: i386, FreeBSD 6.1
Target: MPC850, no BSP with application (hacked to get a bare-bsp lookalike)

bsp_cflg='-mcpu=860 -Dmpc860 -Dmbx860_001b -O4 -fno-keep-inline- functions'
our_cflg='-ggdb3 -D_OLD_EXCEPTIONS'

$base/src/$rtems/configure \
    --enable-rtemsbsp=mbx860_001b \
    --target=powerpc-rtems4.7 \
    --prefix=$base \
    target_alias=powerpc-rtems4.7 \
    --enable-maintainer-mode \
    CFLAGS_FOR_TARGET="$bsp_cflg $our_cflg"

Description:

There is a problem with compiler optimization flags that manifested for us in
rtems-4.6.99.3 on powerpc mpc8xx architecture, but I believe it can
cause problems on any
architecture using gcc-4

It was a very hard to track down problem that manifested itself only if
_Thread_Reset_timeslice()
is called on a Thread_Ready_chain element if:

1. The executing thread is the only one that is able to run.

2. It is the last entry in the chain.

3. It is not the only entry in the chain.

What basically happens in _Thread_Reset_timeslice() is that the
element is extracted and
appended in a row by:

_Chain_Extract_unprotected( &executing->Object.Node );
_Chain_Append_unprotected( ready, &executing->Object.Node );

Since it was at the end of the chain anyway it is extraced and
appended at the same place.

The functions _Chain_Has_only_one_node(), _Chain_Extract_unprotected()
and _Chain_Append_unprotected() are all inlined and the optimizer of
gcc puts all pointers in
the chain datastructures into registers.

Since gcc assumes a default of -fstrict-alaising (already present and
set like this in gcc-3)
this causes problems with the chain datastructures and routines that
violate the strict-
aliasing assumption.

The Problem is caused by the coding trick with the chain headers
doubling as overlapping
front and back sentinels:

rtems-4.6.99.3/cpukit/score/include/rtems/score/chain.h:

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

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

In order to make this work the Chain_Control struct is cast in two ways to a
Chain_Node_struct sometimes start of struct aligned (next mapped on
first and previous
mapped on permanent_null) and somtimes like this:

rtems-4.6.99.3/cpukit/score/inline/rtems/score/chain.inl:

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

where (next is mapped on permanent_null and previous on last).

In the case mentioned above this causes a mess-up of the chain datastructure
that causes much later a NULL pointer dereferenced.

This occured only very rarely on a very busy system since the
preconditions don't happen
often.

I verified the generated powerpc assembler code to be in error and
causing the problem.
Unfortunately the analysis is mostly on paper but let feel free to ask
if you need more details.

When rtems is build with -fno-strict-alaising compiler option:

1. Our system runs happily ever after

2. The powerpc assembler code _Thread_Reset_timeslice() hast been verified
as correct by me.

How-To-Repeat:

Very hard.  Best way to verify is to inspect generated powerpc assembler
of _Thread_Reset_timeslice()

Fix:

Add '-fno-strict-aliasing' to cflags when building RTEMS

--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793



References:
C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Kay-Uwe Kasemir
Re: C strict aliasing rules Marty Kraimer
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Kay-Uwe Kasemir
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Andrew Johnson
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Andrew Johnson

Navigate by Date:
Prev: Re: C strict aliasing rules Andrew Johnson
Next: Next R3.14.9 version: -pre2 or -RC1? Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: C strict aliasing rules Andrew Johnson
Next: Re: C strict aliasing rules Till Straumann
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·