public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Klein <mklein@dis.com>
To: law@cygnus.com
Cc: gcc@gcc.gnu.org
Subject: Re: MPE Port
Date: Tue, 26 Oct 1999 19:52:00 -0000	[thread overview]
Message-ID: <4.2.0.58.19991026192215.00c71830@garfield.dis.com> (raw)
In-Reply-To: <18424.940989664@upchuck>

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			

WARNING: multiple messages have this Message-ID
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	[thread overview]
Message-ID: <4.2.0.58.19991026192215.00c71830@garfield.dis.com> (raw)
Message-ID: <19991031233500.QUMFSFOIKxAG7amU-32hcPLietWk1soSKJk7t5p4f8Q@z> (raw)
In-Reply-To: <18424.940989664@upchuck>

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			

  reply	other threads:[~1999-10-26 19:52 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-07  8:42 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-10-25 22:41 ` Jeffrey A Law
1999-10-26  7:03   ` Mark Klein
1999-10-26 19:12     ` Jeffrey A Law
1999-10-26 19:52       ` Mark Klein [this message]
1999-10-31 23:35         ` Mark Klein
1999-10-31 23:35       ` Jeffrey A Law
1999-10-31 23:35     ` Mark Klein
1999-10-31 23:35   ` Jeffrey A Law
  -- strict thread matches above, loose matches on Subject: below --
1999-09-06 10:40 Mark Klein
1999-09-08  1:41 ` Jeffrey A Law
1999-09-08  6:37   ` Mark Klein
1999-09-30 18:02     ` Mark Klein
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-08  1:39 ` Jeffrey A Law
1999-09-08  6:35   ` Mark Klein
1999-09-15  2:52     ` Jeffrey A Law
1999-09-15  8:26       ` Mark Klein
1999-09-30 18:02         ` Mark Klein
1999-09-30 18:02       ` Jeffrey A Law
1999-09-30 18:02     ` Mark Klein
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-08  1:49 ` Jeffrey A Law
1999-09-08 20:31   ` Mark Klein
1999-09-30 18:02     ` Mark Klein
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-07  2:38 ` Jeffrey A Law
1999-09-07  6:39   ` Mark Klein
1999-09-08  0:45     ` Jeffrey A Law
1999-09-08 20:04       ` Mark Klein
1999-09-15  2:47         ` Jeffrey A Law
1999-09-15  8:32           ` Mark Klein
1999-09-30 18:02             ` Mark Klein
1999-09-30 18:02           ` Jeffrey A Law
1999-10-09 20:18           ` Mark Klein
1999-10-14  4:03             ` Jeffrey A Law
1999-10-14  7:20               ` Mark Klein
1999-10-14 10:45                 ` Jeffrey A Law
1999-10-14 11:05                   ` Mark Klein
1999-10-31 23:35                     ` Mark Klein
1999-10-31 23:35                   ` Jeffrey A Law
1999-10-31 23:35                 ` Mark Klein
1999-10-31 23:35               ` Jeffrey A Law
1999-10-31 23:35             ` Mark Klein
1999-11-08 19:34           ` Mark Klein
1999-11-08 19:54             ` Jeffrey A Law
1999-11-09  6:52               ` Mark Klein
1999-11-30 23:37                 ` Mark Klein
1999-11-30 23:37               ` Jeffrey A Law
1999-11-30 23:37             ` Mark Klein
1999-09-30 18:02         ` Mark Klein
1999-09-30 18:02       ` Jeffrey A Law
1999-09-30 18:02     ` Mark Klein
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-10-25 22:32 ` Jeffrey A Law
1999-10-26  6:51   ` Mark Klein
1999-10-26 19:05     ` Jeffrey A Law
1999-10-26 19:21       ` Mark Klein
1999-10-31 23:35         ` Mark Klein
1999-10-31 23:35       ` Jeffrey A Law
1999-10-31 23:35     ` Mark Klein
1999-10-31 23:35   ` Jeffrey A Law
1999-09-06 10:40 Mark Klein
1999-09-08  1:40 ` Jeffrey A Law
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:40 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:39 Mark Klein
1999-09-07  3:20 ` Jeffrey A Law
1999-09-07  6:46   ` Mark Klein
1999-09-08  0:43     ` Jeffrey A Law
1999-09-30 18:02       ` Jeffrey A Law
1999-09-30 18:02     ` Mark Klein
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:39 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-09-06 10:39 Mark Klein
1999-09-30 18:02 ` Mark Klein
1999-08-27 17:20 HARD_REGNO_MODE_OK on PA-RISC (revisited) Mark Klein
1999-08-29  3:19 ` Jeffrey A Law
1999-09-06 10:39   ` MPE Port Mark Klein
1999-09-30 18:02     ` Mark Klein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.2.0.58.19991026192215.00c71830@garfield.dis.com \
    --to=mklein@dis.com \
    --cc=gcc@gcc.gnu.org \
    --cc=law@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).