Kernel oops with 0.42 on ARM

Michael Miller
Wed Mar 15 20:40:00 GMT 2006

Dan Kegel wrote:
>Three ideas:
>0) turn off gcc's strict aliasing (-fno-strict-aliasing) if it's not off
>and otherwise crank down the optimization.  If that makes the
>problem go away, great.  Otherwise:
>1) run the gcc regression test suite
>Yes, this is a pain, but so is everything else!
>If this finds unexpected failures, great; file bugs for them
>at gcc's bugzilla.   And/or:
>2) add a debug print statement to the kernel at the very
>beginning and make sure you can see it when the kernel
>boots.  Then:
>  a) add more print statements in the code after the last print
>      statement you saw when you booted last
>  b) build, reboot, go back to step a
>Eventually you'll narrow down the offending code, and can
>look at the problem in more detail by examining the generated code.
>Once you find it, you may be able to tweak the source to avoid it.
>File a bug with gcc's bugzilla with the offending code, what got generated,
>and what you had to do to work around it.
>Have fun!
>- Dan

Excellent.  After a couple of late nights of building various tool chains I
was pretty foggy.  These are exactly the kinds of hints I needed.  I'll let
you know what I find.


For unsubscribe information see

More information about the crossgcc mailing list