wot to do with the Maverick Crunch patches?
Tue Apr 1 02:11:00 GMT 2008
On Mon, 31 Mar 2008 11:31:01 +0000 (UTC), "Joseph S. Myers"
> On Mon, 31 Mar 2008, Hasjim Williams wrote:
First of all thanks for replying to this e-mail. You seem to be the one
who has written most of the ARM coprocessor patches in the past, so
logically you're the best person to ask for most of these questions.
> > If someone can get iwmmxt support working in everything, then we might
> > be able to do the same for MaverickCrunch, since it is very similar work
> > to get one ARM coprocessor working as it is to get another working.
> > Half of the support for the iWMMXt processor has already been written
> > and there is proper documentation. Currently iwmmxt is only enabled in
> > certain applications in openembedded (rather than system-wide) because
> > of this reason. I am not sure if it is only exception unwinding that
> > isn't working on iWMMXt, or if there is something else that also needs
> > to be written.
> iWMMXt unwind support has been in GCC since my patch
Thanks for that. I think I saw this patch a while ago, but of course
forgot that it wasn't merged into 4.2.2, only 4.3.0.
> That illustrates the sort of thing that needs changing to implement
> support for a new coprocessor. Obviously you need to get the unwind
> specification in the official ARM EABI documents first before
> it in GCC
Any idea of who to contact and/or how to get this done?
> 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:
Am I reading this right (according to sec 9.3 from ARM IHI 0038A):
unwind.d / unwind_vxwords.d patch tests:
d0c6c1c1 -> [d0] Pop VFP D-D, [c6c1] Pop iWMMXt wR-wR,
[c1] Pop iWMMXt wR-wR
b0b0c0c6|c1c1c6d0 -> Haven't decoded this, but it hasn't changed since
before your patch
c6c0b0b0 -> [c6c0] Pop iWMMXt wR-wR, [b0] Finish, [b0] Finish
unwind.s is a simple test to save iWMMXt, and unwind.d does the unwind
for it? Your patch adds code to test for the incorrect merging test?
gcc uses the code in unwind-arm.c etal to call the functions
(create_unwind_entry, unwind_save_mv etc) binutils gas/config/tc-arm.c
to do the frame unwinding, right? To do the unwind parsing (of table 4
from 9.3 in IHI 0038A), what function in binutils gas/config/tc-arm.c is
I think my problem was that I didn't know what opcode, to use when
calling add_unwind_opcode from within s_arm_unwind_save_mv in the above
binutils-crunch.patch, so I incorrectly used the code (i.e. copy/paste)
to unwind a mmxwr data reg.
Also should aebi_set_public_attributes in binutils/gas/config/tc-arm.c
be setting an EABI attr for MaverickCrunch?
Can we use gas or its testsuite to test each MaverickCrunch operation
easily? I've disabled certain MaverickCrunch operations from gcc,
because I found them to be buggy. I am not sure if this is because the
instruction is incorrectly encoded, or because of some inherit flaw with
> For setjmp/longjmp support in glibc you also need to get an HWCAP value
> allocated in the kernel.
elf_hwcap |= HWCAP_CRUNCH;
The cirrus kernel patches from arm.cirrus.com add the necessary kernel
support, but I think it is also in mainstream linux.
Also, can I assume that running the testsuites (binutils, gcc and glibc)
is the best way to determine what is missing from the current
binutils - http://sourceware.org/binutils/docs/
- "make check" from gas build directory, eg:
gcc - http://gcc.gnu.org/testing/
- "make check-gcc" and "make check-gcc-c++" from gcc build
- "make check" from glibc build directory, eg:
And of course your paths need to be setup along with dejagnu, etc...
More information about the Binutils