wot to do with the Maverick Crunch patches?
Joseph S. Myers
Tue Apr 1 14:16:00 GMT 2008
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:
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
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
More information about the Binutils