Hi again I've been looking at the options we were talking about to make the ARM Debian EABI port work on armv4 as well as armv4t and above and it seems to me that there is a simpler solution.
Rather than have me mangle gcc to support new function exit sequences, with all the possibility of introducing subtle bugs that that entails, can we not simply compile the standard Debian ARM EABI port for armv4 with -mno-thumb-interwork? That should work fine on everything, not add extra instructions and slowness for everyone and, according to the GCC manual page, will also remove a small size and speed overhead that interworking-capable code incurs. (Note: in ARM GCC, -mno-thumb-interwork is the default, while with EABI it is -mthumb-interwork) What is lost is the ability to compile a program in Thumb mode and link it against the standard Debian libraries. I would think that people who need space optimisation would do better to join the people who build their own repositories optimised for their specific CPU (which will give thumb-capable repositories for all thumb-capable CPUs). In any case, you would get a much greater space reduction by building (or using) a pure-Thumb repository than by just recompiling the biggest applications in thumb mode and using the standard libraries and utilities. Does anyone really win by having us bulk out and slow down the whole distro a ilttle with thumb capability so as to be able to compile just one or two programs in thumb mode? I know the ARM EABI spec "mandates thumb interworking", but supporting it seems to be making us make several global slowdowns for it in the Debian port to gain a minor ability of dubious value, compared to just saying -march=v4 -mno-thumb-interwork and having optimal armv4 code for everyone. Opinions? M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
