This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Kernel oops with 0.42 on ARM


Dan Kegel wrote:
>Three ideas:
>0) turn off gcc's strict aliasing (-fno-strict-aliasing) if it's not off
>already
>and otherwise crank down the optimization.  If that makes the
>problem go away, great.  Otherwise:

Strict aliasing was already disabled.  The code had -Os, which is O2 unless
size is affected.  I tried O0 but had problems with inlining.  Without
rearranging source code I couldn't build the kernel except with O1.  With O1
I still had problems.

>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:

I had a devil of a time getting the jail setup.  Specifically I got a
permissions problem in chrootshell.c on the chroot() invocation that I
tracked down to not setting the file permissions on chrootshell to 4755.
That happened because my BusyBox didn't have a link for install.  Also
Busybox related, I needed to user "cp -d /bin/* /jail/bin" to get the
files into the jail because my BusyBox wasn't configured to have the
stand-alone install capability via "busybox --install -s".

After some tweaks to crosstest.sh's board .exp creation section so that
ssh and scp were being used, I was able to get the test suite to run.
While there were some errors, it doesn't look like anything significant.
For example, the floating point underflow causing a signal test failed or
the accuracy of a floating point trig function failed.  The test failures
fell into the categories of math precision/exceptions, dynamic library
loading problems or thread cancellation issues.  Given that the tests all
executed (no oops) that suggests the compiler is basically working.  I had
one parameter error on the tf_waitid test due to what looks like an old
WEXITED flag issue discussed a couple of years back.

>2) add a debug print statement to the kernel at the very
>beginning and make sure you can see it when the kernel
>boots.

Haven't gotten to this yet, but will let you know what I find.

>Have fun!
>- Dan

	Regards,
	Mike


--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]