From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Klein <mklein@dis.com>
To: law@cygnus.com
Cc: gcc@gcc.gnu.org
Subject: Re: MPE Port 
Date: Sun, 31 Oct 1999 23:35:00 -0000
Message-ID: <4.2.0.58.19991026192215.00c71830@garfield.dis.com>
References: <4.2.0.58.19991026065301.00c68310@garfield.dis.com> <18424.940989664@upchuck>
X-SW-Source: 1999-10n/msg00669.html
Message-ID: <19991031233500.QUMFSFOIKxAG7amU-32hcPLietWk1soSKJk7t5p4f8Q@z>

At 08:01 PM 10/26/99 -0600, Jeffrey A Law wrote:

>I'm interested in how/where are dynamic libraries loaded, does the dynamic
>linker make a distinction between code & data in the dynamic library, if
>so, does it arrange to load them in different spaces (which would be a
>significant divergence from the hpux dynamic linker).

Aha.

The short answer is "yes" - data and code are loaded into separate spaces
and the XRT is constructed at load time to point to the space as well as
the offset of each routine that will be referenced in a "shared" library.

[The long answer follows]

But, once a library is loaded by the first reference, all other users will
reference the same code space (it won't be different between concurrent,
but it could be different between separate invocations of the same
program if the program isn't concurrently accessed).

Code lives in SR4 space, and SR4 will change based on the library
where the code lives. The initial program exists in one space. Each
loaded library lives in its own space, and the entry and exit stubs
are responsible for setting SR4.

Here is a sample stack trace for a printf():

$1e ($60) nmdebug > tr,d,i
        PC=a.00ef5264 FWRITE
NM* 0) SP=41855830 RP=a.00ef5230 ?FWRITE+$8
          export stub: 16c.003f6cf4 _process_output+$e0
NM  1) SP=41855830 RP=16c.003f6fc4 _px_write+$1c8
NM  2) SP=41855770 RP=16c.003f6de8 ?_px_write+$8
          export stub: 2c5.00012c60 write+$20
NM  3) SP=418556b0 RP=2c5.0000d8f0 _xflsbuf+$a4
NM  4) SP=41855670 RP=2c5.0000c1f8 _doprnt+$274
NM  5) SP=41855630 RP=2c5.0000af20 printf+$44
NM  6) SP=418536b0 RP=2c5.0000abe8 main+$28
NM  7) SP=41853670 RP=2c5.00000000
      (end of NM stack)
$1f ($60) nmdebug >

The main program is in space 0x2c5, the shared library containing _px_write()
is 0x16c, and finally FWRITE is in space 0xa. The ?FWRITE entry is a stub that
makes sure SR4 is correct:

$21 ($60) nmdebug > dc ?FWRITE+8,7
SYS $a.ef5230
00ef5230  ?FWRITE+$8      4bd53fc9  LDW      -28(0,30),21
00ef5234  ?FWRITE+$c      4bc23fd1  LDW      -24(0,30),2
00ef5238  ?FWRITE+$10     00153820  MTSP     21,4
00ef523c  ?FWRITE+$14     e0402000  BE       0(4,2)
00ef5240  ?FWRITE+$18     4bdb3fc1  LDW      -32(0,30),27


>__gcc_plt_call is necessary because the hpux dynamic linker will not allow
>the return address for a call to be in a non-text, non-shlib space when the
>target function is lazily bound.

Looks like I'm going to face the same problem we did when porting Sun's JIT
to MPE because code must be in a page specifically marked as a code page and
not in a data page. I will need an MPE variation of __gcc_plt_call. This
may be problemmatical because MPE also uses multiple privilege rings and
this code will at least have to be at ring 2. OK ... I'll face that hurdle
when the time comes.

Thanks!
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available