svn commit: r223307 - head/sys/vm

[Warner Losh]

On Jun 21, 2011, at 5:29 PM, Bruce Evans wrote:

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

Yup.

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

I'm not sure what you are saying...

Warner