x-debbugs-cc: email@example.com; firstname.lastname@example.org
(note for non-debian people reading this, the version of clang in debian wheezy is a 3.0 based version which already has patches to make it invoke the linker with appropriate arguments. The llvm version also appears to be 3.0 again somewhat patched by debian)
I recently discovered that the version of clang in debian wheezy and raspbian wheezy does not work correctly on either debian armhf or raspbian. It seems the problem is that clang can't work out what CPU type it should be using and defaults to something very low (specifically arm7tdmi). With this CPU selected clang silently fails to properly use the hard float ABI and as such any armhf code it generates is broken and won't call floating point routines correctly. It also causes an assertion failure in the bfd linker (but links successfully with the gold linker). Setting the CPU type to something sensible makes it implement the hard float ABI correctly and also stops the assertion failure in the bfd linker.
I have managed to figure out how to patch clang to change the default CPU for armhf (patch attatched). However i'm not sure what it is best to set it to for debian armhf*. In particular this block of code from just below where my patch is applied seems to map all armv7 variants to a CPU type of "coretex-a8".
return llvm::StringSwitch<const char *>(MArch)
.Cases("armv4", "armv4t", "arm7tdmi")
.Cases("armv5", "armv5t", "arm10tdmi")
.Cases("armv5e", "armv5te", "arm1026ejs")
.Cases("armv6", "armv6k", "arm1136jf-s")
.Cases("armv6z", "armv6zk", "arm1176jzf-s")
.Cases("armv7", "armv7a", "armv7-a", "cortex-a8")
.Cases("armv7r", "armv7-r", "cortex-r4")
.Cases("armv7m", "armv7-m", "cortex-m3")
.Cases("armv6m", "armv6-m", "cortex-m0")
// If all else failed, return the most base CPU LLVM supports.
Now it is my understanding that "traditional cortex a8" includes CPU features not required by debian armhf. Specifically neon and the extra vfp registers. The questions I have are
1: What does the "coretex-a8" CPU setting imply for clang/llvm? in particular does it imply neon and the extra vfp registers?
2: If noone can provide an answer to the above question then taking into the account how late we are in the freeze should we play it safe and specify a lower (armv6) CPU version to make sure that neon and the extra vfp registers don't get accidently used. I personally think that the answer is yes but I'm open to arguments.
If I get no response to this within about a weak I intend to attach a nmu diff containing a version of the patch that sets the default set to armv6. Then file a pre-approval request with the release team. Finally if the release team approves and noone objects I intend to upload the NMU.
29-set-default-cpu-for-armhf.diff (1.46 KB)