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>