I've just tracked down why some binaries mysteriously code dump on sun3x.
The problem lies in a difference between the sun3 and sun3x placement of
the user stack in virtual memory.

The sun3 hardware architecture does not use all 32 bits of the virtual
address generated by the CPU.  It uses only 28 of the bits and ignores
the upper four.  To keep things consistent within the NetBSD/sun3
code, all fixed addresses for various virtual memory boundaries
such as the start of the kernel text and default load location for shared
libraries were designed with the upper four bits zeroed out.  An example
that will be contrasted in the next paragraph is the kernel text boundary.
On the sun3 it has been set to 0x0e000000.

In the sun3x architecture all 32 bits are used.  Not wanting to throw away
this precious resource (virtual memory space), we decided to locate the
kernel at the traditional SunOS base, 0xf8000000.  This places the kernel
much 'farther' away from user text and code, giving them more room to
grow.  When we moved the kernel, we also decided to move the user stack,
which traditionally has always begun at the kernel text boundary.

Unfortunately, there are a few routines in the sun3 binary set that assume
that the user stack is located at 0x0e000000.  When these routines try to
modify this space in memory on the sun3x, they generate a segmentation
violation.

The offending code in ftpd (the first program found to exhibit this
behavior) the setproctitle() function in the standard C library.  Any
other program which uses setproctitle() is affected as well.  (Sendmail is 
a popular example).

Some solutions are:

* Move the sun3x USRSTACK to the sun3 location.
* Adjust the upper four ignored bits in the sun3 location to move it into
  an acceptable sun3x location.
* Make USRSTACK a variable and not a #define.
* Something we have not thought of yet.

This is an ugly bug, but we're all entomologists.  In the meantime I will
try to make available a patched libc and affected static binaries (if they
exist).

-J