Date: Wed, 18 Feb 2009 14:33:47 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: xcllnt@mac.com Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips Message-ID: <20090218.143347.466770936.imp@bsdimp.com> In-Reply-To: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> References: <BE046876-F8EF-4269-9CD6-743483EC1869@mac.com> <20090218.120514.831271136.imp@bsdimp.com> <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com>
Marcel Moolenaar <xcllnt@mac.com> writes:
:
: 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.
I don't think that's a viable option. MIPS doesn't have a 64-bit
mode, but rather is always 64-bit.
Or rather right now even in the port we have that supports n32 and n64
along side of o32, it is A or B or C.
: > 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...
So far the number of places we've had to change in the kernel is
minimal for the current ABI. The newer ABI is indeed targeted more at
software that's been traditionally developed for x86 hardware.
: > : 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 :-)
Yes. In a closed environment, you have that option.
: > 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...
Other systems on mips are a mixed bag. Some allow user land fixup,
while others abort the application... I think we need more real-world
experience for which one is the best approach...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090218.143347.466770936.imp>