On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope michael.hope@linaro.org wrote:
In general the product should move forward and drop work-arounds like -mimplicit-it. We (the greater ARM community) should fix these package problems as they are found. Here's a bunch of quick-fire statements:
* Qt is currently broken on ARM multiprocessor systems * Qt provides a QAtomic class which provides atomic functions on integers and pointers * You can call different functions depending on your ordering constraints * GCC's __sync primitives are ordered only * The ARMv6 QAtomic implementation only provides ordered versions * AVR32 currently uses the sync primitives in the same way
So there's a precedent there for __sync primitives and they'd be equivalent to what is already there. If RVDS also supports __sync_* (Richard?) then we can also delete the RVDS specific code.
The kernel adds -mimplicit-it via its own build rules. What else needs -mimplicit-it? Matthias, are you running a rebuild at the moment? How many extra packages have failed?
I had a play with the Maverick GCC-4.5 and binutils. This code:
void foo() { asm("it eq\n\t" "teqeq r2,#1" ); }
compiles fine with -marm, -mthumb, and -march=armv4t -marm. It seems the assembler accepts IT instructions in both unified and compatibility modes.
Interesting... it this is indeed true then it could provide a way forward. I don't know which binutils versions will support this -- Richard may be able to comment.
Note that -mimplicit-it is a sort of anti-workaround: I believe the design intent of the unified assembler syntax was that programmers should not normally write IT explicitly (since that obviously makes code harder to port and maintain ... as we're discovering). So the native behaviour of the RVCT assembler is the like the implicit-it behaviour, and gas (and GCC inline asm) are incompatible with this behaviour by default.
Of course, there's no technical reason why the behaviour has to be the same across different toolchains, but since the alternative is to patch all the inline assembler in the world ... and out-of-line assembler too if we want to migrate that to thumb ... and since the kernel at least is unlikely to do this, it does at least seem worth trying to make the case to upstream.
Of course, it's possible this has all been tried before and will be a foregone conclusion... so if people still disagree then that's fair enough.
If all gas that we care about accept IT instructions in separated syntax mode, then this does at least make it feasible to put the ITs in manually without resorting to preprocessor hacks. But it may still be a lot of work.
Cheers ---Dave