Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 22.214.171.124
ralf.corsepius at rtems.org
Thu Dec 7 10:39:59 CST 2006
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 , 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
> 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
> 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.
More information about the rtems-users