[Gc] mips support broken in gc-7.x (and other pending patches)
ths at networkno.de
Thu Jul 3 19:21:19 PDT 2008
Boehm, Hans wrote:
> Thanks for testing.
> > -----Original Message-----
> > From: Thiemo Seufer [mailto:ths at networkno.de]
> > /*
> > * FIXME: This should probably make finer distinctions. SGI MIPS is
> > * much more strongly ordered, and in fact closer to sequentially
> > * consistent. This is really aimed at modern embedded
> > implementations.
> > * It looks to me like this assumes a 32-bit ABI. -HB */
> > The MIPS architecture specification allows for weaker
> > ordering than what SGI used to implement. Since most modern
> > MIPS SMP implementations use a weak ordering variant, with
> > "sync" being the only common barrier operation, I implemented
> > the variant which works on all MIPS systems.
> Is there now an official specification? If so, I fully agree that we
> should make only assumptions stated there. Last I looked, things
> seemed unclear, which is why I suggested considering multiple options.
MIPS Technologies provides a number of specifications on its website
www.mips.com, which is somewhat vague, and company internal
documentation which is clearer. (I was a MIPS employee until a few
> > As long as AO_t is a 32-bit quantity the code should also work on
> > N32/N64 ABIs, although I haven't tested this.
> AO_t is defined to match the size of pointers.
Then it should work for N32 but not for N64.
> > > I noticed that in a couple of places, the atomic_ops patches don't
> > > seem to take advantage of the structure of the package. If
> > you omit
> > > operations, it tries to synthesize them from the exisiting ones.
> > > Mips.h seems to supply implementations for things like
> > > AO_compare_and_swap_acquire that look like they should be
> > equivalent
> > > to the automatically generated ones. Is there a reason not to take
> > > those out?
> > IIRC I carried those forward from an earlier version of
> > libatomic_ops, where they weren't automatically generated. If
> > that changed now then the versions in mips.h are redundant.
> I think that, at least for this package, they were always intended to
> be automatically generated, though there may have been issues there.
The Debian-packaged standalone version of libatomic-ops had such a
problem at some point. Maybe the archived bug reports carry some
useful information WRT that, and the m68k patch:
More information about the Gc