[head tinderbox] failure on mips/mips

[Marcel Moolenaar]

On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote:
> : In other words: by tweaking the alignment of 64-bit types in
> : n32, you prohibit GCC from using the 64-bit capabilities of
> : the processor and MIPS isn't so weird anymore.
>
> I think so, but there's a twist.
>
> On MIPS, one kernel supports multiple ABIs at the same time.  I'm not
> entirely sure how the routing interface would cope with this sort of
> thing because the size of u_long changes.  I need to do some more
> research to see what's going on there...

Hmm... My first reaction is not to go there right away. It's
probably safer or go the amd64 route: keep ILP32 and LP64
distinct. We have the infrastructure in place and we can
always optimize and blend once things are working.

> There are other ABIs on ARM that don't suffer from these problems.  We
> should investigate using them.

I agree. It's better for FreeBSD/arm in particular if it's
more like FreeBSD/i386. It may not be best for the ARM
port in absolute sense, but we only have a few developers
working on non-i386 hardware and a whole lot of developers
who don't care about non-i386...

> : The point being that programmers *do* code with certain
> : assumptions and as soon as those assumptions don't hold on
> : a platform, you end up worse off. My thoughts for MIPS n32
> : are to make it behave like any "normal" 32-bit strong-
> : alignment platform to avoid 1) a large number of runtime
> : alignment faults -- which are a bigger performance bottleneck
> : than forcing 64-bit integrals to be accessed with 2 32-bit
> : accesses
>
> Run time faults aren't a bottleneck.  They are a core dump, which is
> why I'm looking at this in the first place. :)

:-)

> : At Juniper I changed the ARM compiler default by adding:
> : 	-mstructure-size-boundary=8
> :
> : That made life a *lot* simpler and performance hasn't been
> : sacrificed.
>
> Except you've invented a new ABI by doing that...

We have a products to make and a source base to work
with. Swimming upstream is best left to salmons :-)

>  I think that the
> project should look at transitioning to a different ABI that works
> better.  ARM has several to choose from...

I tend to agree.


> It also turns out that in this case, a simple (void *) is safe and
> causes no issues because that time_t isn't accessed...  It does give
> one time to pause and think about it.

Fair enough. Misalignment in process space can easily be
made non-fatal, in which case it's mostly a performance
problem. That makes the problem space much more contained
and therefore easier to deal with...

-- 
Marcel Moolenaar
xcllnt at mac.com