Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Dec 2000 23:08:38 -0500 (EST)
From:      <atrens@nortel.ca>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        <current@FreeBSD.ORG>
Subject:   possibly related data point - (was) Re: Current Broken!
Message-ID:  <Pine.BSF.4.30.0012072234320.29280-100000@hcarp00g.ca.nortel.com>
In-Reply-To: <XFMail.001207193941.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

John,

I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in

/usr/src/sys/i386/atomic.h .

# make atomic.o
cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. -I/usr/src/sys
-I/usr/src/sys/../include
-I/usr/src/sys/contrib/dev/acpica/Subsystem/Include  -D_KERNEL -include
opt_global.h -elf  -mpreferred-stack-boundary=2 -fomit-frame-pointer
/usr/src/sys/i386/i386/atomic.c
In file included from /usr/src/sys/i386/i386/atomic.c:48:
machine/atomic.h: In function `atomic_set_char':
machine/atomic.h:178: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_char':
machine/atomic.h:179: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_char':
machine/atomic.h:180: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_char':
machine/atomic.h:181: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_short':
machine/atomic.h:183: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_short':
machine/atomic.h:184: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_short':
machine/atomic.h:185: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_short':
machine/atomic.h:186: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_int':
machine/atomic.h:188: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_int':
machine/atomic.h:189: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_int':
machine/atomic.h:190: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_int':
machine/atomic.h:191: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_long':
machine/atomic.h:193: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_long':
machine/atomic.h:194: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_long':
machine/atomic.h:195: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_long':
machine/atomic.h:196: inconsistent operand constraints in an `asm'
*** Error code 1

with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer
is optimizing out the offending contraints.  Ouch. Probably not what was intended.

Maybe this is what's biting you ?

I cut and pasted the cc command, inserted a -E, removed the #line
directives, and captured the offending lines - since my mailer doesn't
like really long lines, I've folded them - each function previously
occupied a single line.

void
atomic_set_char (volatile u_char  *p, u_char  v){
    __asm volatile (  "orb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}

void
atomic_clear_char (volatile u_char  *p, u_char  v){
    __asm volatile ( "andb %b2,%0" : "=m" (*p) :  "0" (*p), "ir" ( ~v ));
}

void
atomic_add_char (volatile u_char  *p, u_char  v){
    __asm volatile ( "addb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}

void
atomic_subtract_char (volatile u_char  *p, u_char  v){
    __asm volatile ("subb %b2,%0" : "=m" (*p) :  "0" (*p),  "ir" ( v ));
}

void
atomic_set_short (volatile u_short  *p, u_short  v){
    __asm volatile ("orw %w2,%0" : "=m" (*p) :  "0" (*p), "ir"  ( v ));
}

void
atomic_clear_short (volatile u_short  *p, u_short  v){
    __asm volatile ("andw %w2,%0"  : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}

void atomic_add_short (volatile u_short  *p, u_short  v){
    __asm volatile ("addw %w2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_short (volatile u_short  *p, u_short  v){
    __asm volatile ("subw %w2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_set_int (volatile u_int  *p, u_int  v){
    __asm volatile ("orl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_clear_int (volatile u_int  *p, u_int  v){
    __asm volatile ("andl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( ~v ));
}

void atomic_add_int (volatile u_int  *p, u_int  v){
   __asm volatile ("addl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_int (volatile u_int  *p, u_int  v){
    __asm volatile ("subl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_set_long (volatile u_long  *p, u_long  v){
    __asm volatile ("orl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_clear_long (volatile u_long  *p, u_long  v){
    __asm volatile ("andl %2,%0" : "=m" (*p) :  "0" (*p), "ir" (  ~v ));
}

void atomic_add_long (volatile u_long  *p, u_long  v){
    __asm volatile ("addl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_long (volatile u_long  *p, u_long  v){
    __asm volatile ("subl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

So there you have it. I'll step back now since I haven't done any x86
assembly since 1986 ... and this is readily reproduceable in -current.

Hope this helps,

Cheers,

Andrew.




On Thu, 7 Dec 2000, John Baldwin wrote:

> Date: Thu, 07 Dec 2000 19:39:41 -0800 (PST)
> From: John Baldwin <jhb@FreeBSD.ORG>
> To: The Hermit Hacker <scrappy@hub.org>
> Cc: freebsd-current@FreeBSD.ORG
> Subject: Current Broken!
>
>
> On 08-Dec-00 The Hermit Hacker wrote:
> >
> > Just upgraded the kernel, rebooted and it hung/panic'd with:
> >
> > panic: spin lock sched lock held by 0x0xc02a73el for > 5 seconds
> > cpuid = 1; lapic.id = 01000000
> > Debugger("panic")
> >
> > I have DDB enabled, and ctl-alt-esc doesn't break to the debugger, so its
> > totally hung here ...
> >
> > dual-cpu celeron, smp enabled ...
> >
> > Marc G. Fournier                   ICQ#7615664               IRC Nick:
> > Scrappy
> > Systems Administrator @ hub.org
> > primary: scrappy@hub.org           secondary:
> > scrappy@{freebsd|postgresql}.org
>
> Yes.  Something is broken with mutexes for the non-I386_CPU (and thus for SMP)
> case in -current with the latest commit to i386/include/mutex.h.  Of course,
> you can revert that commit and then your kernel won't compile....  In the code
> I've looked at so far, it looks like possibly a weird register allocation bug
> in gcc and/or another weird nuance in the register constraints.  In the
> specific case I am looking at, the mtx_exit() of Giant in STOPEVENT in
> syscall2() failed to properly release an unrecursed, uncontested Giant in
> mtx_exit() and fell through to mtx_exit_hard(), which assumes that Giant is
> either recursed or contested.  When I disassembled the kernel and looked at the
> code, gcc assumed that when it looked up curproc for the mtx_enter() operation
> (which executed ok as far as I can tell), it could leave the value of curproc
> cached in %edi _across_ the call to the stopevent() function.  My only guess is
> that %edi was clobbered during stopevent(), causing the cmpxchgl to fail, and
> throwing the code into mtx_exit_hard() when it shouldn't have. :(
>
> If anyone is an expert at register constraints, etc., please feel free to look
> at the macros in src/sys/i386/include/mutex.h
>
>

-- 

+--
| Andrew Atrens                 Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own,  not those of any employer. |
                                                               --+
 Berkeley had what we called "copycenter", which is "take it down
 to the copy center and make as many copies as you want".
                 -- Kirk McKusick



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.30.0012072234320.29280-100000>