e5a8a9b897
systems running a BSD-ish server. No dynamically linked executable support (it requires weird execve() hacks...), nor any Mach trap support. But it ran lots of statically linked binaries well enough for me to get bootstrapped.
78 lines
3.4 KiB
Plaintext
78 lines
3.4 KiB
Plaintext
$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.
|
|
|
|
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.
|
|
|
|
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[]);
|
|
|
|
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.
|
|
|
|
2. Changing execve() to support OSF/1 dynamically linked executables.
|
|
|
|
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.
|
|
|
|
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.)
|
|
|
|
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.
|
|
|
|
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
|