sys/compat/osf1/README.dynamic

   1 $NetBSD: README.dynamic,v 1.2 1999/04/27 06:39:49 cgd Exp $
   2
   3 Dynamically linked programs are supported by NetBSD's Digital UNIX
   4 (formerly DEC OSF/1) emulation.  The OSF/1 dynamic linker scheme is
   5 described in fair detail in:
   6
   7         %A Larry W. Allen
   8         %A Harminder G. Singh
   9         %A Kevin G. Wallace
  10         %A Melanie B. Weaver
  11         %T Program Loading in OSF/1
  12         %P 145-160
  13         %I USENIX
  14         %B USENIX Conference Proceedings
  15         %D January 21-25, 1991
  16         %C Dallas, TX
  17         %W Open Software Foundation
  18
  19 Additionally, the object file formats in use are described in the
  20 Digital UNIX _Assembly Language Programmer's Guide_ which can be
  21 found (among other places) on a version-specific page off of:
  22
  23         http://www.unix.digital.com/faqs/publications/pub_page/doc_list.html
  24
  25 Finally, the actual representation of Auxiliary Vectors came from information
  26 in the Digital UNIX auxv.h header file.
  27
  28 There are at least two potential issues with the implementation as it
  29 currently exists:
  30
  31 1. exec_with_loader() is not emulated.
  32
  33         Most uses of dynamically linked programs come through execve()
  34         and use the default loader (/sbin/loader).  In Digital UNIX
  35         (and OSF/1) you can also force a specific loader to always be
  36         invoked to load an executable by using the exec_with_loader()
  37         system call.  Few, if any, programs use this feature.
  38
  39 2. It is not immediately obvious that the right values are used for
  40    text and data locations when invoking a dynamically linked executable.
  41
  42         The text and data sections, and the break, are set up as if
  43         /sbin/loader itself had been executed.  It's not clear that this
  44         is correct, but /sbin/loader seems to expect that at least the
  45         break will be set up this way.
  46
  47         This has certain implications for the way mmap() behaves.  See
  48         the comment in the osf1_mmap() function in osf1_misc.c.
  49
  50 3. The stack location is used is the normal NetBSD/alpha stack location.
  51
  52         No attempt is made to put the stack in the place where
  53         Digital UNIX would normally put it.  This may confuse some
  54         programs.