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.
>#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 <[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
