Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update for current reality

Browse Source
This commit is contained in:
cgd 1999-04-27 16:08:40 +00:00
parent b69c7692af
commit 1f9cfb5d53
1 changed files with 41 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
sys/compat/osf1/README.dynamic
View File

@ -1,80 +1,54 @@
$NetBSD: README.dynamic,v 1.2 1999/04/27 06:39:49 cgd Exp $
$NetBSD: README.dynamic,v 1.3 1999/04/27 16:08:40 cgd Exp $
XXX As of right now, dynamically linked programs are supported, and
XXX this document is out of date. I'll update it when i get the chance.
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:
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.
%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
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.
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:
1. Implementing osf1_exec_with_loader().
http://www.unix.digital.com/faqs/publications/pub_page/doc_list.html
The description of osf1_exec_with_loader is as follows:
Finally, the actual representation of Auxiliary Vectors came from information
in the Digital UNIX auxv.h header file.
int exec_with_loader(int flags, const char *loader,
const char *file, char * const argv[],
char * const envp[]);
There are at least two potential issues with the implementation as it
currently exists:
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.
1. exec_with_loader() is not emulated.
2. Changing execve() to support OSF/1 dynamically linked executables.
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.
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.
2. It is not immediately obvious that the right values are used for
text and data locations when invoking a dynamically linked executable.
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.)
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.
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.
This has certain implications for the way mmap() behaves. See
the comment in the osf1_mmap() function in osf1_misc.c.
3. Extending the pmap code to handle larger virtual spaces.
3. The stack location is used is the normal NetBSD/alpha stack location.
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.
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.
-- cgd
No attempt is made to put the stack in the place where
Digital UNIX would normally put it. This may confuse some
programs.