On Sat, 10 Jul 1999, Matthew Dillon wrote:
>
> The supposedly atomic functions in i386/include/atomic.h are not
> as atomic as was previously thought :-):
>
> #define atomic_add_short(P, V) (*(u_short*)(P) += (V))
>
> I looked at that kinda funny. But C doesn't guarentee a RMW opcode
> for a "+=" !!!. Alan found an example showing a load, add, and
> separate store by disassembling the kernel. An interrupt occuring in
> the middle of that sequence would lead to the reported problems.
>
> I'm pretty sure this is the problem causing the "objtrm" lockups. I've
> submitted a patch to Alan to make those atomic_*() functions inline
> assembly.
>
> There also appear to be a number of mistakes in some of the inline
> assembly already laying around -- some of it appears to specify output
> arguments for RMW instructions without also indicating to the compiler
> that those are input arguments as well, leading to bogus optimizations
> by the C compiler. The 'setbits' function is the one Alan found
> inadvertantly while we were trying to figure out why my first iteration
> didn't work. heh heh. Alan will fix the setbits inline.
>
> It wouldn't hurt if someone with more assembly experience could audit
> all of the inline assembly present in the source base.
>
> I am re-running the 16MB/make -j5 buildworld test to see if this has
> really fixed the problem.
What a nightmare. This must be due to egcs compiling things differently
from gcc 2.7.1. I should have guessed when people started talking about
objtrm (I spent many unhappy hours looking for objtrm bugs on the alpha)
but my attention was elsewhere.
Before I fixed this stuff for the alpha, the += expressions were
scattered all over the source tree. At least you get to fix the macro :-).
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
