[src/netbsd-1-4]: src/sys/compat/osf1 pull up rev(s) 1.2-1.3 from trunk. (cgd)

[cgd <cgd%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/abba365eefa3
branches:  netbsd-1-4
changeset: 468843:abba365eefa3
user:      cgd <cgd%NetBSD.org@localhost>
date:      Mon Jun 21 19:23:47 1999 +0000

description:
pull up rev(s) 1.2-1.3 from trunk. (cgd)

diffstat:

 sys/compat/osf1/README.dynamic |  109 ++++++++++++++++------------------------
 1 files changed, 43 insertions(+), 66 deletions(-)

diffs (124 lines):

diff -r d20e32338766 -r abba365eefa3 sys/compat/osf1/README.dynamic
--- a/sys/compat/osf1/README.dynamic    Mon Jun 21 19:23:38 1999 +0000
+++ b/sys/compat/osf1/README.dynamic    Mon Jun 21 19:23:47 1999 +0000
@@ -1,77 +1,54 @@
-$NetBSD: README.dynamic,v 1.1 1995/02/13 21:39:01 cgd Exp $
-
-Currently, the NetBSD OSF/1 emulation code only supports statically
-linked OSF/1 binaries.  This document is meant to be a quick
-description of what would need to happen to support dynamically linked
-OSF/1 binaries, and to provide an indication of the amount of work
-that would be required to add such support.
+$NetBSD: README.dynamic,v 1.1.26.1 1999/06/21 19:23:47 cgd Exp $
 
-To support dynamically linked OSF/1 binaries, three steps would have
-to be taken:
-       (1) The osf1_exec_with_loader() syscall emulation code would
-               have to be written.
-       (2) Execve() would have to be changed to support invocation of
-               a loader for dynamically linked binaries.
-       (3) The pmap code would have to be extended to allow process
-               virtual spaces that are much larger than are currently
-               allowed.
+Dynamically linked programs are supported by NetBSD's Digital UNIX
+(formerly DEC OSF/1) emulation.  The OSF/1 dynamic linker scheme is
+described in fair detail in:
 
-1. Implementing osf1_exec_with_loader().
-
-The description of osf1_exec_with_loader is as follows:
-
-       int exec_with_loader(int flags, const char *loader,
-               const char *file, char * const argv[],
-               char * const envp[]);
+       %A Larry W. Allen
+       %A Harminder G. Singh
+       %A Kevin G. Wallace
+       %A Melanie B. Weaver
+       %T Program Loading in OSF/1
+       %P 145-160
+       %I USENIX
+       %B USENIX Conference Proceedings
+       %D January 21-25, 1991
+       %C Dallas, TX
+       %W Open Software Foundation
 
-It invokes the program named by file, with the given argv and envp,
-by starting the specified loader (or /sbin/loader) and somehow passing
-the flags, file name, argv, and envp in such a way that the
-appropriate things will happen with them.  This interface is
-completely undocumented (in the documentation that we have available),
-and so the only way to figure it out is to disassemble the OSF/1
-kernel and/or /sbin/loader.
+Additionally, the object file formats in use are described in the
+Digital UNIX _Assembly Language Programmer's Guide_ which can be
+found (among other places) on a version-specific page off of:
 
-2. Changing execve() to support OSF/1 dynamically linked executables.
+       http://www.unix.digital.com/faqs/publications/pub_page/doc_list.html
+
+Finally, the actual representation of Auxiliary Vectors came from information
+in the Digital UNIX auxv.h header file.
 
-Normally, dynamically linked executables are invoked using execve(),
-in the normal fashion.  The kernel transforms that request into one
-that uses the loader, and causes the loader to be invoked with the
-appropriate information to run the target executable.
+There are at least two potential issues with the implementation as it
+currently exists:
+
+1. exec_with_loader() is not emulated.
 
-The mechanism by which this is done is unknown; it may be possible to
-completely replace the OSF/1 loader with one designed for NetBSD, but
-that is rather prohibitive.  (Additionally, it wouldn't solve the
-problem of needing to implement the osf1_exec_with_loader()
-functionality.)
+       Most uses of dynamically linked programs come through execve()
+       and use the default loader (/sbin/loader).  In Digital UNIX
+       (and OSF/1) you can also force a specific loader to always be
+       invoked to load an executable by using the exec_with_loader()
+       system call.  Few, if any, programs use this feature.
 
-In any case, this would not be insignificant; it and/or the
-implementation of osf1_exec_with_loader() would probably require a
-complete rewrite or duplication of the current execve() code.
-
-3. Extending the pmap code to handle larger virtual spaces.
+2. It is not immediately obvious that the right values are used for
+   text and data locations when invoking a dynamically linked executable.
 
-OSF/1's /sbin/loader wants to be loaded at 0x3ff80000000.  Currently,
-because of a simplifying assumption (specifically, to only use the
-first level-one pte for user-space mappings, effectively turning the
-pmap into one that looks much like one for a mc68030), only 8Gb
-(0x200000000 bytes) of user virtual space are supported.
-
-It is unclear that the extra virtual space is necessary for any
-applications that NetBSD/Alpha would be used for, and support for it
-would add a significant amount of complexity to the pmap module.
-Adding that support would probably require a from-scratch rewrite of
-the pmap module.
+       The text and data sections, and the break, are set up as if
+       /sbin/loader itself had been executed.  It's not clear that this
+       is correct, but /sbin/loader seems to expect that at least the
+       break will be set up this way.
 
+       This has certain implications for the way mmap() behaves.  See
+       the comment in the osf1_mmap() function in osf1_misc.c.
 
-Because of the difficulties in emulating the system call interface
-used to run dynamic executables, and the difficulties in allowing
-support for the address space the OSF/1 loader needs, I do not think
-that it is feasible to support dynamically linked OSF/1 executables
-with the OSF/1 loading mechanism.  It may be possible to do so with a
-new loading mechanism which could be written for NetBSD, but it is
-unclear that the necessary interfaces to do even that could be
-discovered, and the effort required to implement a new loading
-mechanism would be prohibitive.
+3. The stack location is used is the normal NetBSD/alpha stack location.
 
--- cgd
+       No attempt is made to put the stack in the place where
+       Digital UNIX would normally put it.  This may confuse some
+       programs.