Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 188.8.131.52
joel.sherrill at oarcorp.com
Thu Dec 7 16:11:02 UTC 2006
>> 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
something. I know you are diffing .s files but any differences as a 1st
Is it possible to could load and store instructions in the two generated
.s files and see
if the count differed?
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
definitely a HIGH candidate for breakage check by hand
I think the role of the user community is to help review the candidates
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.
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
have no FPU instructions.
More information about the users