On Sat, Jun 13, 2009 at 06:25:14PM +0200, Kevin D. Kissell wrote:
> Calling a function does not cause replication of its symbols. That
> would happen if it were a macro, or an inline function, but not a simple
> global function, which r4k_wait_irqoff is supposed to be, since (at
> least the last time I worked with it), it is only called indirectly by
> having its address stored in the cpu_wait function pointer. Either your
> compiler is doing something insane and replicating the function each
> time its address is taken (!), or someone has added another __pastwait
> symbol somewhere.
>
> And you are correct that moving the symbol to another function risks
> breaking the functionality. Even if the compiler didn't reorder things -
> which you are correct to note that it might do - you would create a
> window during which the kernel would mistakenly believe that the CPU was
> in the interrupt-disabled wait state when in fact it had just fallen out
> of the loop and serviced an interrupt. I don't think that would
> necessarily be fatal, but it would at least be inefficient.
It depends on how gcc optimized the if statement. Gcc might compile the
function as if it was written like this:
void r4k_wait_irqoff(void)
{
local_irq_disable();
if (need_resched())
goto nowait;
__asm__(
" .set push \n"
" .set mips3 \n"
" wait \n"
" .set pop \n");
local_irq_enable();
__asm__(
" .globl __pastwait \n"
"__pastwait: \n");
return;
nowait
local_irq_enable();
__asm__(
" .globl __pastwait \n"
"__pastwait: \n");
}
Which isn't quite the brightest thing to do but perfectly legal. As for
gcc follow the old motto trust is futile, suspicion breeds confidence.
Ralf
