blob: b8bba3b7badf97b1c1374658932ff982fd4eb05e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
$OpenBSD: README.dynamic,v 1.5 2001/07/09 05:15:23 fgsch Exp $
$NetBSD: README.dynamic,v 1.2 1999/04/27 06:39:49 cgd Exp $
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:
%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
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:
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.
There are at least two potential issues with the implementation as it
currently exists:
1. exec_with_loader() is not emulated.
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.
2. It is not immediately obvious that the right values are used for
text and data locations when invoking a dynamically linked executable.
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.
3. The stack location is used is the normal NetBSD/alpha stack location.
No attempt is made to put the stack in the place where
Digital UNIX would normally put it. This may confuse some
programs.
|
