[Gc] mips support broken in gc-7.x (and other pending patches)

Thiemo Seufer 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
months ago.)

> > 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:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=1;dist=unstable;package=libatomic-ops;repeatmerged=1


Thiemo


More information about the Gc mailing list