From owner-freebsd-current Mon Jan 15 11:48:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id AB38737B699 for ; Mon, 15 Jan 2001 11:47:24 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0FJjo191256; Mon, 15 Jan 2001 11:45:50 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010115092544.U91029@gsmx07.alcatel.com.au> Date: Mon, 15 Jan 2001 11:47:21 -0800 (PST) From: John Baldwin To: Peter Jeremy Subject: Re: Atomic breakage? Cc: current@FreeBSD.org, Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Jan-01 Peter Jeremy wrote: > On 2001-Jan-14 23:02:28 +0200, Mark Murray 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 -- 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