I recompiled part of Xt with debugging and linked it statically into
an emacs.  with the fixes to unexelf.c to handle mdebug on mips, I
found that the underlying problem is a bad relocation.

widget.c declares an initialized Xt widget structure,
emacsFrameClassRec.  the superclass of that struct is initialized to
&widgetClassRec (which is defined inside libXt).  emacsFrameClass is a
pointer which is initalized to &emacsFrameClassRec.

xfns.c:x_window() passes emacsFrameClass to XtCreateWidget().  But
when XtCreateWidget walks up it superclass hierarchy, instead of
getting &widgetClassRec as the superclass, the value read from the
statically-initialized struct is exactly twice what it should be.

nm -p on the Emacs binary show that widgetClassRec is an unresolved
external reference. So it must be the dynamic linker which is screwing
up, though I have no idea what's causing it to get confused.

(fwiw: widgetClassREc is defined in Xt's Core.o. Statically linking
Core.o into the emacs binary gets past this bug, but soon trips up
over what looks like another insstance of the same thing.  Or it may
be an xsrc compatiblity problem: the only xsrc tree I had on the pmax
at home is an ancient one from 1998).