>Number:         20246
>Category:       port-mips
>Synopsis:       libposix broken on MIPS (at least)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-mips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 07 17:27:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Chris Demetriou
>Release:        1.6N as of 2003-02-05 00:00 UTC.
>Organization:
>Environment:
uname -mrs:
NetBSD 1.6N sbmips
w/ a GENERIC kernel.
>Description:
libposix on NetBSD MIPS ports is broken.

in the case of errors, __cerror is used... but __cerror
is in libc and for dynamically-linked executables
(the default), the first time each libposix fn gets
an error it has to bind __cerror.  doing that corrupts
the register (v0 on MIPS) used to indicate errno!

PR marked as high priority because it causes MIPS ports
to fail the existing regression tests.
>How-To-Repeat:
run the regress/lib/libposix/prn1 test on mips.

i came to the hypothesis above by modifying the test code to
do the rename of no/such/file/or/dir twice, with printouts
between them.  In that case, only the first failing rename
produces a bogus errno!
>Fix:
unknown.  Possibilities include:

* making libposix include its own copy of __cerror.

	I don't know what's involved in this one...

* making ld.so not clobber v0 on mips.

	If this is done, other ports should be checked to
	make sure they don't suffer the same problem.

* making libposix implement its syscalls via syscall().

	This would be fine, but adds a level of indirection.
	I don't know if we care about the absolute performance
	of POSIX chosk(), fchown(), lchown() and rename().

* making libposix implement its syscalls via the underlying __posix_*
  syscalls...

	Again fine, and probably another level of indirection unless
	it used linker/symbol magic (that i am not sure exists.)

>Release-Note:
>Audit-Trail:
>Unformatted: