This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: wot to do with the Maverick Crunch patches?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Hasjim Williams <linux-cirrus at lists dot futaris dot org>
- Cc: Martin Guy <martinwguy at yahoo dot it>, linux-cirrus at freelists dot org, GCC <gcc at gcc dot gnu dot org>, openembedded-devel at lists dot openembedded dot org, binutils at sourceware dot org
- Date: Tue, 1 Apr 2008 14:16:11 +0000 (UTC)
- Subject: Re: wot to do with the Maverick Crunch patches?
- References: <56d259a00803300545t36d77bf2icd9b0ef2ffac3e45@mail.gmail.com> <1206942412.15179.1245142739@webmail.messagingengine.com> <Pine.LNX.4.64.0803311126210.1358@digraph.polyomino.org.uk> <1207015854.25579.1245331423@webmail.messagingengine.com>
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
joseph@codesourcery.com