Subject: RE: mips support changes to libc
To: None <owner-port-pmax@NetBSD.ORG, port-pmax@sun-lamp.cs.berkeley.edu>
From: Adam Glass <adamg@microsoft.com>
List: port-pmax
Date: 08/31/1994 16:05:18
|
| * From src/lib/libc/stdlib/strtod.c, line 192:
|
| #if defined(IEEE_8087) + defined(IEEE_MC68k) + defined(VAX) +
defined(IBM) != 1
| Exactly one of IEEE_8087, IEEE_MC68k, VAX, or IBM should be defined.
| #endif
|
| I think MIPSEL fp is close enough to an 8087 for #define IEEE_8087
| to work, but I'd welcome a second opinion.
JT?
|
| * The .if/.elif/.elif chains in Makefile.inc in
| src/lib/libc/{gen,net,string} need to be updated to reflect the
| contents of mips/arch. Is there some way these Makefiles can include
| a Makefile from ../$(MACHINE_ARCH) instead of explicitly coding in
| the various Makefile.inc, those source modules that have optimized
| assembler versions, for each and every architecture? Or perhaps
| some string derived from $(MACHINE_ARCH_ could be added to VPATH?
|
| Anyway, the patch that I used is appended below.
|
| * The stabs produced by gcc 2.5.8 and 2.6.0 for __warn_references
| on a MIPS don't work with a GNU as that has mips support.
| I don't know how to fix this immediately, so I've temporarily
| commented uses of __warn_references() out of my own source tree.
|
| I'd welcome any better ideas.
|
the warn references should be better conditionalized, i agree
| * I note in passing that PIC code will almost certainly never work on
| a mips processor without support for GP-relative addressing,
| and all that implies. So dynamically-linked shared libraries won't
| work on a MIPS with the native NetBSD tools. And not having GP-relative
| addressing implies a measurable runtime cost, even for statically-
| linked binaries. I've seen reports that GP-relative addressing can
| give a speedup of from 5% to 20%, depending on the code. Personally
| I don't see any gain, and some cost, in using "native" NetBSD a.out
| on mips processors.
|
Well i think it would absolutely stupid and unmanageable for NetBSD to
maintain a seperate tool chain for the MIPs.
However, I would like to pull in some of Ralph's work in doing
GP-relative addressing on a slightly modified a.out. We'll need it for
other architectures in the future any way.
| I understand and will accept arguments that it's better to have a
| single, uniform object format. Personally, I'm still interested in
| running ECOFF executables compiled from native NetBSD source and
| letting them run with p_emul equal to EMUL_NETBSD. I don't expect
| that that is necessarily the best decision for NetBSD as a whole,
| though.
|
unfortunately it really isn't. NetBSD's ultrix compatibility is a nice
feature to have, but it really isn't the point of the exercise.....
|
| *** lib/libc/string/Makefile.inc.DIST Thu Jul 7 01:14:05 1994
| --- lib/libc/string/Makefile.inc Wed Aug 31 03:00:04 1994
| ***************
| *** 1,5 ****
| # from: @(#)Makefile.inc 5.6 (Berkeley) 3/5/91
| ! # $Id: Makefile.inc,v 1.28 1994/07/06 04:07:53 mycroft Exp $
|
| # string sources
| .PATH: ${.CURDIR}/arch/${MACHINE_ARCH}/string ${.CURDIR}/string
| --- 1,5 ----
| # from: @(#)Makefile.inc 5.6 (Berkeley) 3/5/91
| ! # $Id: Makefile.inc,v 1.1 1994/07/07 08:14:05 jonathan Exp jonathan $
|
| # string sources
| .PATH: ${.CURDIR}/arch/${MACHINE_ARCH}/string ${.CURDIR}/string
| ***************
| *** 41,46 ****
| --- 41,50 ----
| SRCS+= bcmp.c bcopy.c bzero.S ffs.S index.c memchr.c memcmp.c memset.c \
| rindex.c strcat.c strcmp.c strcpy.c strcspn.c strlen.S \
| strncat.c strncmp.c strncpy.c strpbrk.c strsep.c \
| + strspn.c strstr.c swab.c
| + .elif (${MACHINE_ARCH} == "mips")
| + SRCS+= bcmp.S bcopy.S bzero.S ffs.S index.S memchr.c memcmp.c memset.c \
| + rindex.S strcat.c strcmp.S strcpy.c strcspn.c strlen.S \
| strspn.c strstr.c swab.c
| .endif
|
|
|
------------------------------------------------------------------------------