Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!Venus.YCC.Yale.EDU!LEICHTER
From: LEICHTER@Venus.YCC.Yale.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: shareable-image
Message-ID: <8805161532.AA17326@ucbvax.Berkeley.EDU>
Date: 14 May 88 20:19:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 41


	The problem is how to override a routine in a shareable image.  The
	image contains several routines, say 1000 and many of those call
	another routine (say QNEXTE) in the same image. QNEXTE  in turn, calls
	another routine, say, QNEXT. In VAX macro the call is (in QNEXTE):

	       CALLS   #0,QNEXT

	The trouble is that QNEXT is supposed to be a user supplied routine
	while I had to include a dummy routine QNEXT in the shareable image
	since everything must be linked. When the user links his main program
	and his own QNEXT with the shareable image the linker won't accept the
	user supplied routine QNEXT since a dummy version is already in the
	shareable image. How can one owerride the dummy routine?

There is no automatic way to do this.  What you are asking for is essentially
the converse of the usual shareable image mechanism:  A shareable image
provides a table of entry points, and when an image starts up, its indirect
pointers to entry points within the shareable image are resolved into actual
addresses, based on where the shareable image was loaded.  What you want is
for indirect pointers within the shareable image to be fixed up.  This would
require an entirely different mechanism; for one thing, the pointers TO the
shareable image can be, and are, fixed up in place - but the shareable image
itself can't be changed - other processes may be using it.

You'll have to do this yourself:  Within your main code, provide a "transfer
vector table", just like the transfer vector table used in the shareable
image, and handled automatically.  During initialization, provide the address
of the table to the shareable image and have it store it.  Then have the
shareable image, when it wants to call something like QNEXT, actually use
an indirect reference into the "transfer vector table".

The cleanest way to do this may be make the dummy QNEXT contain the code
that finds the appropriate "transfer vector table" entry and calls it.  (Of
course, what it probably does is load the index into R0 and transfer to some
common access code.) Then as far as the rest of the shareable image is
concerned, QNEXT is just a normal function.  If you do this, QNEXT should NOT
be a universal symbol (to avoid complaints from the Linker when the "real"
QNEXT gets defined).

							-- Jerry