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