Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Ralf Corsepius]

On Thu, 2006-12-07 at 10:11 -0600, Joel Sherrill wrote:
> >   
> >>  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 [1], I haven't found
> > any :)
> >   
> 
> I haven't seen your script but know a bit of your procedure so am going 
> to propose
> something.  I know you are diffing .s files but any differences as a 1st 
> order check.
Yes. I am compiling all BSPs with "default CFLAGS" and with
"-fno-strict-aliasing" added, all BSP's CFLAGS changed to -O2 (-g
removed) and am comparing the disassembly.

> Is it possible to could load and store instructions in the two generated 
> .s files and see
> if the count differed?
Probably doable, but I haven't tried to do so.

> for all files and multilib variants and (eventually) all BSPs
>   (a) compile with and without strict aliasing
>   (b) objdump .o and diff generated .s files
>   if diff shows no changes
>      OK.. strict aliasing did not change output, go on to the next file
>   else
>      count load and store instructions in both .s files
>     if counts are same
>        the file is 
> OK                                                               # is 
> this true?

Except of "counting" and not yet having tried multilibs, that's
essentially what I am doing (One iteration takes approximately one
day!).

>     else
>        definitely a HIGH candidate for breakage check by hand
> 
> I think the role of the user community is to help review the candidates 
> Ralf's automated
> procedure identifies and suggest ways to lower the number of false 
> positives.  We can't
> realistically check 20K files every time gcc bumps a version.

Let me put it this way: Spraying "const's" to (esp. pointer) arguments
of inline functions, so far had been a fairly effective way to eliminate
a fair number (In the range of 1000) of "candidates" ;)

"const'ing arguments" of inline functions, definitely is only affecting
"aliasing" as a "random side-effect" (due to const's having an impact on
optimization), but this is what had eliminated the Peer/Thomas case.

> If no different in .s OR ld/st counts are sufficient to say strict 
> aliasing had no bad impact,
> then it is much easier to check the code automatically.
> 
> A similar technique could also be used to verify that soft-float/integer 
> only executables have no FPU instructions.

Ralf