This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wot to do with the Maverick Crunch patches?


On Tue, 01 Apr 2008 12:10:54 +1000, "Hasjim Williams"
<linux-cirrus@lists.futaris.org> said:
> 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
> called?

To answer my own question:

gcc/gcc/config/arm/pr-support.c -> __gnu_unwind_execute

uws is the GNU unwinding state as defined in unwind-arm.h

e.g. for VFP
gnu_Unwind_Save_VFP in libunwind.S called from unwind-arm.c /
_Unwind_VRS_Pop

I'm not sure at the moment, what regclass (UVRSC) MaverickCrunch
registers are being classed as.  I guess with my invalid
binutils-crunch.patch they would be classed as UVRSC_WMMXD...  Which
never "worked" (or even compiled) in gcc 4.2.2 or gcc 4.1.2 since
Joseph's patch hadn't been merged in, and so the opcode c6 or c1 etc
would fail.

I suppose we need a DEMAND_SAVE_MAVERICK like DEMAND_SAVE_VFP WMMXD etal
...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]