On 20-Jul-16 16:19, Julius Werner wrote:
Well... honestly, isn't it our fault for uprevving to a buggy toolchain? If there was a way to write this code such that it will result in the binary output ARM wants and works on all versions, submitting a patch to them would be reasonable... but otherwise I can kinda understand that they don't want to use an inferior solution because we insist on using an assembler that doesn't know how to assemble stuff correctly. Isn't the best solution to only uprev archs that really need new compiler features until the GCC guys manage to produce a stable version?
Yes, I was wrong. After reading the other threads and talking with Martin, it indeed seems to be a toolchain issue. However, the new toolchain had many advantages over the previous one, and the code was not in (our) ARM TF at the time we uprevved.
The maintenance burden of keeping different versions of toolchains supported for different architectures as part of the reference toolchain is imho almost always significantly higher than actually fixing the issues. (Especially if they are not time critical)
Martin produced a binutils fix for the issue. Whether the binutils people will find it to be the "right" fix is still to be found out, but it seems to allow compiling the latest, unmodified ARM TF.
Stefan