Date: Mon, 15 Jan 2001 11:47:21 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: current@FreeBSD.org, Mark Murray <mark@grondar.za> Subject: Re: Atomic breakage? Message-ID: <XFMail.010115114721.jhb@FreeBSD.org> In-Reply-To: <20010115092544.U91029@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-Jan-01 Peter Jeremy wrote: > On 2001-Jan-14 23:02:28 +0200, Mark Murray <mark@grondar.za> wrote: >>Hi John >> >>There seems to be same breakage in the atomic stuff: >> >>link_elf: symbol atomic_load_acq_int undefined >>KLD file random.ko - could not finalize loading >> >>I back out the latest commit to sys/i386/include/atomic.h, and things >>work a bit better (on my laptop). > > Basically, the problem is that some of the recent commits have broken > the interface between sys/i386/include/atomic.h and sys/i386/i386/atomic.c > > The latter file builds non-inlined versions of the atomic functions > defined in atomic.h. This means that atomic.h must be laid out in a > suitable manner so that the non-inlined functions are built by > atomic.c. (Modules use explicit function calls, rather than inlined > atomic functions to remove the need to have distinct UP and SMP > versions.) > > The layout of atomic.h should look like: > > >#ifdef KLD_MODULE >#defines expanding to prototypes. >#else >#defines expanding to inline function definitions >#endif > List of atomic functions (invoking above macros) > > > Due to incompatibilities between __asm in different versions of gcc, > several different versions of various macros (and expansions) are > necessary. The old asm should probably die for one thing. > The problem is that over time, atomic.h has been expanded and things > have gotten a bit confused. > > Mark's reported breakage is a result of the new atomic_cmpset_int(). > This has been defined in the !KLD_MODULE section (but only for new > versions of gcc - which should be OK since it'll never be used in > conjunction with the old gcc) and a suitable prototype has been > inserted in the KLD_MODULE section. The problem is that a pile of >#defines have been incorrectly put in this section, rather than > outside the KLD_MODULE section. This means that modules are > left with dangling references to these functions. Actually, the problem is that I changed atomic_load and atomic_store to be functions for modules instead of inlines because they are now different for I386_CPU. It seems that static versions aren't being compiled of these functions. I'll fix it in a second. atomic_cmpset_* are fine, however. > And for BDE's benefit - atomic.h is broken for IA32's with 64-bit > longs. (I believe that can be fixed for Pentiums and above using > CMPXCHG8B, but I can't test the code). The i386 with 64-bit longs doesn't boot from what I hear. Also, long in machine/types.h is 32-bits long. I don't think we need to bother with 64-bit longs. Adding 64-bit atomic ops will be expensive on <= 486. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010115114721.jhb>