Subject: mips support changes to libc
To: None <port-pmax@sun-lamp.cs.berkeley.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 08/31/1994 15:34:24
*  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.

*  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.

*  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.

   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. 


*** 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
  

------------------------------------------------------------------------------