Article 4495 of vmsnet.internals: Path: nntpd.lkg.dec.com!depot.mro.dec.com!pa.dec.com!decwrl!tribune.usask.ca!rover.ucs.ualberta.ca!hookup!news.mathworks.com!mvb.saic.com!macro32 From: Brian Schenkenberger Newsgroups: vmsnet.internals Subject: RE: Requesting help on sliced images Message-ID: <0099DD58.AA7CC4C1.33@ALPHA.WKU.EDU> Date: Tue, 13 Feb 1996 05:00:32 CST Organization: Macro32<==>Vmsnet.Internals Gateway X-Gateway-Source-Info: Mailing List Lines: 77 Mark Berryman writes: >Problem: > I need to call an entry point in a shareable image. Said entry point > is defined as a global (and, thus, present in an STB file) but it not > defined as a Universal symbol (the image is question is 3rd party so > relinking is not an option). > >Original solution: > The image name is known, the address from the .STB file is known. > So, follow the data structure pointed to by CTL$GL_IMGLSTPTR to find > where the shareable image was loaded into memory, add in the value > obtained from the .STB file and I now have the relocated address of > the entry point in question. > >New Problem: > The shareable image is now sliced and installed resident in order to > provide resident data and shareable address linkages. Naturally, this > means that simply adding an offset to the base of the shareable image > isn't going to work anymore. > > So, I'm looking for information on how to find a particular entry point > in a sliced image once it is loaded into my address space. I have VAX > listings but not Alpha (yet). My copy of the Alpha I&DS manual is the > preliminary version in which I have not yet been successful in finding > this discussed. > You're warm on the .STB trail... >Can any of you kind folks help? Slicing is simply an organization of the execlet into large areas mapped by single PTEs/TBs with a granularity hint. The underlying organization of the image doesn't change dramatically. In one of my DECUS presentations on porting, I demonstrated a little hack to do something very similar to what I believe you're looking to do. To invoke a routine in alpha, you need to know the address of the routine's procedure descriptor and not it's actual code address. The PDSC$Q_ENTRY field of the PD will maintain its code address. I was after the routine LDR$FINAL_UNLOAD which is a global symbol in the .STB but, has no vector defined in the base image. What I did was to use the address of another available routine, in this case, LDR$UNLOAD_IMAGE. Then, I had a routine, called GET_FU for GET_F(inal)U(nload) which opened and read the .STB file for the execlet SYSLDR_DYN where both of these routines are found. THis routine scans through the .STB and gets the image value of both the LDR$UNLOAD_IMAGE and LDR$FINAL_UNLOAD routines. Then, the routine obtains the address of the "loaded" LDR$UNLOAD_ROUTINE and applies the "bias" (the difference of the two image values) to the address of LDR$UNLOAD_IMAGE to obtain the address of the PDSC of LDR$FINAL_UNLOAD. It's a bonafide hack but, it works! Because the execlet can only have a single IDS of a select set of IDS types, the linkage sections of the image will reside in one of two sections: NONPAGED,RESIDENT,R/W or PAGED,R/W and the code in NONPAGED,RESIDENT,R/O or PAGED,R/O. However, the relative positions of the PDSCs of the routines will not change. Therefore, if you can locate one routine, sliced or otherwise, the relative positioning of its relative's PDSCs should not change. I can send you the code examples if you send me a private e-mail. The examples are fairly simple and unencumbered by lots of error checking and miscellaneous code; they're intended to simply and clearly demonstrate this hack and a few other porting techniques WHICH _I_ DEVELOPED AND ARE NOT THE PROPRIETARY TECHNOLOGY OF ANY INDIVIDUAL OR CORPORATION! VAXman - Say what you want/Say what you will/'Cos I find you think what makes it easier And lies spread on lies/We don't care/Belief is our relief/We don't care - Tears For Fears: the hurting/ideas as opiates -