On 14-Jan-01 Peter Jeremy wrote:
> On 2001-Jan-14 23:02:28 +0200, Mark Murray <[EMAIL PROTECTED]> 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.
>#defines expanding to inline function definitions
> 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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to