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