On Jun 21, 2011, at 5:29 PM, Bruce Evans wrote: > 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.
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 _______________________________________________ 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"
