>optimistation. For some reason changing the top level CFLAGS (was this the
>wrong place to do it) has resulted in the makefile deciding to recompile
>everything.
That's deliberate. The makefile tracks the flags for each source file and
recompiles any whose flags have changed.
> 1: ldrbt r6,[r6],#0
>
>I don't recognise the t flag, and I can't remeber what happens with ldr
>(ldm, IIRC, does the writeback after the first register load, but all that
>might have changed/become undefined with StrongARM) but the instruction as
>shown looks very odd - is it a very expensive No-op? Or is it doing something
>cunning? Should the #0 be pre-increment instead?
>(b.t.w. I get no warnings with -O2, which was what I was using)
What the instruction is trying to do is load the word pointed to by R6 and
store the result back in that same register. It's not a no-op. The T flag
means to do the access as if from user mode; this is probably a get_user call.
Technically the results are UNPREDICTABLE if the two registers are the same.
I guess get_user needs to tell gcc that the input and output regs mustn't
overlap. If you send me a fragment of code that exhibits the problem I'll
cook up a fix.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
