Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 126.96.36.199
strauman at slac.stanford.edu
Thu Dec 7 12:48:04 CST 2006
Ralf Corsepius wrote:
> On Thu, 2006-12-07 at 09:47 +0100, Wolfram Wadepohl wrote:
>> Till Straumann schrieb:
>>> I agree with Linus' sentiment, too. The problem, however,
>>> is (repeating mantra) that this is not just some weirdo
>>> gcc optimization that can be switched off. It is the C99 *standard*.
>>> Even if you can switch this off for gcc today, there is no
>>> guarantee that you will be able to in the future or on other
>>> compilers. If we want to produce C99 compliant code then
>>> we must comply with the alias rule. period.
>>> Steven Johnson wrote:
>>>> I have been quietly following this thread, but I find the whole
>>>> -fstrict-aliasing/-fnostrict-aliasing issue to be very disturbing.
>>>> Luckily my program isn't built with -O2 or I probably would have been
>>>> tracking untold numbers of strange bugs in known working code. For
>>>> the C language to change so that a pointer (regardless of the pointer
>>>> type used to reference that memory) no longer points to a known piece
>>>> of memory, in a predictable way is whacked.
>>>> I for one do not look forward to adding __attribute__ ((may_alias)) to
>>>> the hundreds of places where I change the way I address memory using
>>>> pointers. It is a monumental waste of time, prone to error and in my
>>>> opinion putting in declarations to fix a broken compiler
>>>> optimisation. When a compiler optimisation breaks a fundamental
>>>> aspect of C that has existed since the beginnings of the language,
>>>> then I consider that optimisation to be broken, and not the code
>>>> itself. I will be adding -fno-strict-aliasing to all of my builds in
>>>> future, and I will be making sure RTEMS (and all of the other Open
>>>> Source libraries I use) builds with -fno-strict-aliasing, regardless
>>>> of what is ultimately decided here), I just don't want the headache.
>>>> In my opinion you wouldn't be fixing RTEMS by adding these
>>>> declarations or changing the code, you would be working around a
>>>> broken compiler. The other OS's that use -fno-strict-aliasing are (in
>>>> my opinion) doing the right thing. I also fail to see how the option
>>>> could yield any tangible benefits on performance that would warrant
>>>> the pain and difficulty it causes.
>>>> But that is my 2c.
>> Hi all,
>> i've follwed the discussion on the list. As a user of RTEMS building
>> comercial *embedded* applications with high availability the only short
>> term solution is to use -fno-strict-aliasing for the whole program
>> including all RTEMS parts.
>> Till is right in telling us the gcc optimization (weird or not) *is* C99
> I agree with Till and you.
>> Following this argumentation and expecting that
>> -fno-strict-aliasing will be dropped eventually and also considering that
>> we write embedded code dealing with real hardware i ask the question if C
>> is the right language to implement these applications in the future. A
>> programming language forcing me to consider what machine code the compiler
>> will eventually produce is not worth using for *embedded* programming.
> Well, let me put this way: There are people having tried to (ab-)use C
> as macro assembler. C99 (probably under the influence of C++) has voided
> this aspect to a large extend and shifted to a different level of
> programming languages (more into Pascal's direction).
> As most high level applications don't apply such "assembler like"
> features, so they aren't really affected. And those highlevel
> application which do (esp. some GUI toolkits) are facing similar issues
> as we are.
>> In general and from an academic point of view Ralf is totally right; the
>> standard is clear and the code should be fixed. A proper data model, well
>> designed from base on, will hopefully not produce aliasing problems. But
>> is this always possible and adequate in real work? It shuold be for basic
>> technology like RTOS or general libraries like newlib!
> I think so, but ... as we currently all are experiencing, the "C as
> macro assembler times" seem to be over.
>> In fact the current RTEMS code is not in the shape that aliasing is not
>> considered as a problem. It has grown over more than a decade of years.
>> Is this the time for a complete rewrite?
> Frankly speaking, I think, at least some very basic parts/types RTEMS
> are in need of a redesign/rewrite. IMO, introducing "type strictness"
> and related to it, to "properly-typed" APIs is in dire need.
> RTEMS definitely has weaknesses related to these areas. Therefore, I
> would expect a large amount of the issues related to "strict aliasing"
> and "strict alignment" to collapse, once they would be addressed.
>> Can we fix it?
> I hope so, but do not expect this to happen any time soon.
>> What piece of work
>> can i do, as a user with limited knowledge of kernel functonality?
> Good question.
> ATM, from my point of view, people being familiar with certain flavors
> of asm who could identify aliasing showing effects on RTEMS code would
> be helpful. I have been trying to identify files being affected by
> strict-aliasing and meanwhile have a list consisting of ca. 20000 object
> (Note: *.o not *.c!) files (out of ca. 70000) from RTEMS-4.8, which are
> affected by aliasing.
> Now, identifying those which really are broken by aliasing would be
> necessary. So far, apart of Peer's/Thomas's case , I haven't found
> any :)
Problem with your current approach is that you don't really
find alias rule violations but only the subset of them that
cause problems with current gcc's optimization implementation.
>  Which meanwhile is supposed to be worked-around.
More information about the rtems-users