Hi All,

I am reading the kernel source files of the sparc64 port, and I came
across several points which made me send this mail.

    In the file sys/arch/sparc64/sparc64/asm.h the 32 bit compiler
variant of the macro ldxa seem to clobber a variable without
telling that to gcc. It seem that the macro declares ldxa_tmp for
the purpose of clobbering it, but it is not used, and the variable loc
(%1 in the asm directive) is clobbered.
As far as I can see the line :
__asm __volatile("wr %2,%%g0, %%asi; ldxa [%1]%%asi, %1; stx %1,[%3];...
should be replaced with :
__asm __volatile("wr %2,%%g0, %%asi; ldxa [%1]%%asi, %0; stx %0,[%3];...

Also, throughout this file (asm.h) the location variable is casted to
(long long). For example :
#define	lduba(loc, asi) ({ \
	register int _lduba_v; \
	__asm __volatile("wr %2,%%g0,%%asi; lduba [%1]%%asi,%0" : "=r" (_lduba_v) : 
\
	    "r" ((long long)(loc)), "r" (asi)); \
	_lduba_v; \})
When compiling 32 bit objects, gcc allocates two registers
for loc but when using it only one (the most significant) of them
in the code. The produced code of lduba(17,289) is
  mov    0, %o2
  mov    17, %o3
  mov    289, %o1
  wr %o1, %g0, %asi; lduba [%o2]%asi, %o0
_lduba_v is %o0
This means that we try to load from address zero.
If the macro was more like this
#define lduba(loc, asi) ({ \
	register int _lduba_v; \
        register long _lduba_t; \
        int64_t _lduba_loc = loc; \
        register int64_t *_lduba_loca = &_lduba_loc; \
	__asm __volatile("wr %2,%%g0,%%asi; ldx [%2],%1; " \
            "lduba [%1]%%asi,%0" : "=r" (_lduba_v), "=r" (_lduba_t) : \
	    "r" (_lduba_loca ), "r" (asi)); \
	_lduba_v; \})
It could use a 64 bit address (long long) safely. Again, I may be
missing something. This creates additional overhead, so on 64 bit compiler 
we can use a simpler version.

    In the file sys/lib/libkern/arch/sparc64/_setjmp.S ,
in function _longjmp, the following code is found:
4:
        cmp     %o2, %sp        ! %sp must not decrease
        blt,pn  %icc, Llongjmpbotch
         movge  %icc, %o2, %sp  ! it is OK, put it in place
        jmp     %o3 + 8         ! success, return %g6
         mov    %g6, %o0

This code is common to 64 bit stack as well as 32 bit stack,
yet the branch (blt) depends on %icc. Assume that %o2 is
0x10000000, and %sp is 0x0ffffffff. This will cause us to avoid
the jump, although we should have taken it.
Am I missing some constraint on %sp forcing it to be a 32 bit
address?

    If indeed the points written above or some of them need to be
fixed I will send the diffs of the relevant file to this list.


Thank you,
Michael Adda
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com