On Tue, 21 Jun 2011, Attilio Rao wrote:
2011/6/21 Bruce Evans <b...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
