> I believe that the v4-support in the toolchain was eventually done, > but I'm not sure if it's mainlined, and we definately haven't changed > the default Debian build. Can someone who knows/recalls the details > tell us what the cost of building armel for v4 would be, and if it is > actually possible currently?
AFAIK it hasn't been touched since it was implemented, but I wouldn't expect significant bitrot. In short you need to build with -march=armv4, and pass either --fix-v4bx or --fix-v4bx-interworking to the linker. The former generates binaries that are not EABI compliant, and effectively v4 only. This has no additional overhead compared to armv4t, but if you run such code on a system with Thumb shared libraries then it will break. The latter generates code which is fully EABI compliant, and works on later systems. However it does incur some additional runtime cost. It replaces every indirect branch (including function returns) with a test/conditional branch stub. Unfortunately this doesn't quite work out of the box. While the EABI allows condition codes to be clobbered over a call, a couple of routines in libgcc[1] use a special calling convention and I never got round to fixing them. The fix should be fairly straightforward now we have the .inst directive. If anyone has actual users then I can make a patch. Paul [1] Specifically aeabi_cfcmpeq and aeabi_cdcmpeq. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
