Re: sh3 build error

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Mon, Oct 12, 2009 at 20:28:37 +0200, Havard Eidnes wrote:

> there is a build error which occurs while cross-building
> rf_copyback.c as part of sys/rump/dev/lib/libraidframe for the
> sh3 ports.  The new assembler is apparently more picky, and won't
> let
> 
>       tas.b @(r0,r9)
> 
> pass through, as in this snippet:
[...]
> Nick traced this back to __cpu_simple_lock(), which does this:
> 
> static __inline void
> __cpu_simple_lock(__cpu_simple_lock_t *alp)
> {
> 
>          __asm volatile(
>                 "1:     tas.b   %0      \n"
>                 "       bf      1b      \n"
>                 : "=m" (*alp)
>                 : /* no inputs */
>                 : "cc");
> }
> 
> and apparently the actual pointer isn't readily available in a
> register at that point.
> 
> Even though I don't know the sh3 architecture at all, I hope I
> found a fix for this problem:
> 
> 
> Index: lock.h
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/sh3/include/lock.h,v
> retrieving revision 1.15
> diff -u -p -r1.15 lock.h
> --- lock.h      28 Apr 2008 20:23:35 -0000      1.15
> +++ lock.h      12 Oct 2009 10:23:37 -0000
> @@ -81,9 +81,10 @@ __cpu_simple_lock(__cpu_simple_lock_t *a
>  {
>  
>          __asm volatile(
> -               "1:     tas.b   %0      \n"
> +               "\n"
> +               "1:     tas.b   @%0     \n"
>                 "       bf      1b      \n"
> -               : "=m" (*alp)
> +               : "=r" (alp)
>                 : /* no inputs */
>                 : "cc");
>  }

That will not work.

I've tried to use "=V" but, surprisingly, it gives

    error: inconsistent operand constraints in an 'asm'

which I don't understand, as 'V' is supposed to be an "unoffsetttable"
subset of 'm'.

There's undocumented "=Sr0" constraint that seems to do the right
thing, but I'm afraid that under certain circumstances gcc might
decide to use, say, @(disp, Rn) that does not refer to R0 and so
satisfies Sr0 constraint.

There are few other abominations I tried that seems to generate
correct code in simple test cases, but I'm not happy about them b/c
I'm not sure what exactly they are communicating to gcc.

I've asked gcc folks for guidance.

SY, Uwe
-- 
uwe%stderr.spb.ru@localhost                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen