On 10/13/2011 12:56 PM, MikeW wrote:
> Andrew Haley <aph <at> redhat.com> writes:
>
>>
>> On 10/13/2011 12:23 PM, MikeW wrote:
>>> sh4-linux-gcc (GCC) 4.2.4 [unfortunately the version is tied to the
>>> kernel build. ]
>>>
>>> In some kernel code where RAM is unavailable due to manipulation of
> the MMU,
>>> I wanted to place some 'got here' stops in the code so I could
> ^C break in gdb,
>>> reset a register value and allow execution to continue.
>>>
>>> Accordingly I tried:
>>> volatile register int stop_loop __asm("r5")__;
>>> ...
>>> stop_loop = 0x1234;
>>> (disable MMU)
>>> while (stop_loop != 0);
>>> ...
>>>
>>> which seemed to generate code that checks the value of r5 only once:
>>>
>>> xxxx08: mov r5,r1
>>> xxxx0a: tst r1,r1
>>> xxxx0c: bf xxxx0c ;r5 never tested again!!
>>> xxxx0e: (unrelated code)
>>>
>>> I also tried
>>> while ((volatile)stop_loop != 0);
>>> and
>>> while ((volatile)(stop_loop != 0));
>>>
>>> which both gave the original asm code as above.
>>>
>>> So, in short, is there any way to persuade gcc to reload r5 - which could
>>> in other non-debug situations be a global register variable updated
>>> in an ISR, for example.
>>
>> I don't think so. If every there was a case for "use asm", it's surely
>> this.
>
> Looks like the 'volatile' attribute does not work when registers are involved,
> even though various language standard documents just mention "access to
> an object" rather than stating that the qualifier only applies to
> in-memory "objects".
Indeed, and nowhere does it state what constitutes an access. Besides, named
register variables is a gcc extension.
> The generated code would imply:
>
> if (stop_loop != 0) {
> while (1);
> }
>
> which is not equivalent to my source !
That's true. Maybe we should simply make this case generate a warning.
It doesn't make sense on any level, really.
Andrew.
