On Tue, 1 Apr 2008, Hasjim Williams wrote: > > That illustrates the sort of thing that needs changing to implement > > unwind > > support for a new coprocessor. Obviously you need to get the unwind > > specification in the official ARM EABI documents first before > > implementing > > it in GCC > > Any idea of who to contact and/or how to get this done?
Contact Richard Earnshaw in the first instance. > > and binutils will also need to support generating correct > > information given .save directives for the coprocessor registers. > > http://files.futaris.org/gcc/binutils-crunch.patch almost covers this, > but I don't quite follow your binutils patch: > http://sourceware.org/ml/binutils/2006-08/msg00207.html Since my patch fixes a bug specific to the iWMMXt unwind support, you don't need to follow it; either your binutils patch for your coprocessor will be bug-free, or it will have its own bugs you need to debug yourself, unrelated to the iWMMXt one I fixed. Following the current bug-fixed code would be more useful as an example than following old buggy code and a bug-fix to it. > Also, can I assume that running the testsuites (binutils, gcc and glibc) > is the best way to determine what is missing from the current > MaverickCrunch support? You would be well-advised to add an unwind test similar to the one I added in my GCC patch, to make sure that the Crunch registers are restored correctly. That only covers call-preserved registers. Testing call-clobbered registers is harder (but normally unwind information won't be generated for them, so they matter less); for iWMMXt I tried testing using -fcall-saved-wr0 -fcall-saved-wr1 ... but found that CONDITIONAL_REGISTER_USAGE overrides -fcall-saved-* for the wr registers and there is no prologue/epilogue support for saving/restoring wcgr registers. You may need to temporarily modify GCC to save and restore such registers in order to test the unwinding for them. -- Joseph S. Myers [EMAIL PROTECTED]
