svn commit: r223307 - head/sys/vm

[Bruce Evans]

On Tue, 21 Jun 2011, Attilio Rao wrote:

> 2011/6/21 Bruce Evans <brde at optusnet.com.au>:
>>> vm_page.o: In function `vm_page_clear_dirty':
>>> /sys/vm/vm_page.c:(.text+0x18d0): undefined reference to `atomic_clear_8'
>>> /sys/vm/vm_page.c:(.text+0x18d0): relocation truncated to fit: R_MIPS_26
>>> against `atomic_clear_8'
>>> vm_page.o: In function `vm_page_set_validclean':
>>> /sys/vm/vm_page.c:(.text+0x38f0): undefined reference to `atomic_clear_8'
>>> /sys/vm/vm_page.c:(.text+0x38f0): relocation truncated to fit: R_MIPS_26
>>> against `atomic_clear_8'
>>
>> Atomic types shorter than int cannot be used in MI code, since they might
>> not exist. Â Apparently they don't exist on mips. Â jake@ fixed all their
>> old uses for sparc4 in ~Y2K.
>
> I'm sure they do, they exist in support.S though and may not have the
> _8 form (they may just have the _char version). I may look at the code
> again to be sure.

Perhaps more like the reverse.  They are correctly spelled with _char
form in the C code.  This is needed to match the declarations of the
variables literally.  They are translated to the _8 form by
<machine/atomic.h> but the _8 form doesn't exist.  I think the acq and
rel forms exist in <machine/atomic.h>.  mips/support.S only has a limited
set of atomics, including clear_16 but not including clear_8.

Anyway, they shouldn't be used in either form.  They certainly don't
exist on sparc64, but sparc64 compiles because it is on the other half
of the ifdef.  sparc64 atomic support is actually 4 times smaller than
mips atomic support, not just 2.5 times, since it doesn't have extras
in support.S.

Bruce