charles@TAMVXOCN.BITNET (01/08/88)
I encountered the same problem with BACKUP and VMS 4.6. To get around the PHY_IO problem, you have to install two images. BACKUP has to be installed in with PHY_IO and SYS$LIBRARY:ENCRYPSHR has to be installed. ENCRYPSHR cannot be installed with privs since it is linked with traceback. This will only work if you are not using DIGITAL's encryption software. I think this problem shows up only with the TU81 PLUS and non HSC contollers. Charles D. Boatwright Computer Systems Manager Texas A&M University Oceanography Dept. - 3146 College Station, Texas 77843-3146 409-845-5751 (GTEnet) NEPTUN::CHARLES (THEnet) AEOLUS::CHARLES (THEnet) TAMOCN::CHARLES (SPAN) UTSPAN::UTADNX::NEPTUN::CHARLES (SPAN) UTSPAN::UTADNX::AEOLUS::CHARLES (SPAN) CHARLES@TAMVXOCN.BITNET (BITnet) CHARLES@NEPTUN.TAMU.EDU (INTERnet) CHARLES@AEOLUS.TAMU.EDU (INTERnet)
rrk@byuvax.bitnet (01/11/88)
Five minutes with PATCH can make your /TRACEBACK image /NOTRACEBACK. I have done this numerous times to install images originally linked /TRACEBACK. Use PATCH/ABSOLUTE so that you can access the image header. The twelve bytes, usually starting at byte 48 of the image header (30 hex for PATCH) are transfer addresses. A normal shareable image linked with /TRACEBACK has one transfer address, as opposed to /NOTRACEBACK which has none. Replace this one (at byte 48) with a zero, and you have it. There will still be some extra debugger information at the end of the image file, but it will be ignored. You can also reverse the process to debug any system image linked /NOTRACEBACK.
levy@ttrdc.UUCP (Daniel R. Levy) (01/17/88)
In article <55rrk@byuvax.bitnet>, rrk@byuvax.bitnet writes: #> Five minutes with PATCH can make your /TRACEBACK image /NOTRACEBACK. I #> have done this numerous times to install images originally linked /TRACEBACK. #> Use PATCH/ABSOLUTE so that you can access the image header. The twelve #> bytes, usually starting at byte 48 of the image header (30 hex for PATCH) #> are transfer addresses. A normal shareable image linked with /TRACEBACK #> has one transfer address, as opposed to /NOTRACEBACK which has none. Replace #> this one (at byte 48) with a zero, and you have it. There will still be #> some extra debugger information at the end of the image file, but it will #> be ignored. You can also reverse the process to debug any system image #> linked /NOTRACEBACK. Ok, when "reversing the process" what value do you write into byte 48 (and the following bytes)? You could record this information somewhere for an image that was originally /TRACEBACK and that you manually modified with PATCH to be /NOTRACEBACK as described above, but what if it never was /TRACEBACK??? -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
rrk@byuvax.bitnet (01/20/88)
I posted a short patcher to make /NOTRACEBACK images debugable several months ago. I just discovered that it has been trashed on this system. I will post it tomorrow. This is how it works: Try linking an image two ways, first /NODEBUG/TRACEBACK and then /NODEBUG/NOTRACEBACK. You will find that the images have the following three slots for transfer vectors (usually at byte 48). In a /notraceback image, there will only be one transfer vector, directly to the main entry point. In the /traceback version, the first transfer address is somewhere in the 7fffffff control region, and the second is the main transfer address. But there are NO additional images in the list of referenced images. This address is the same for all images linked /TRACEBACK. All you have to do is move the longword at offset 48 to 52 and put this special address into the longword at offset 48 and it works. I do it all the time. You will have to do a RUN/DEBUG so that it will run debug since it was linked /NODEBUG. But if you take the byte stored at offset 32 and (even in a /NODEBUG image and make it odd (by adding one) the image flags will say that the image was linked debug and you can even activate it debug from a command in DCLTABLES. This is very useful for debugging VMS images (shipped /NOTRACEBACK/NODEBUG) which must be activated from a DCL command, since you can't use the run/debug command or it will get errors about entities missing from DCLTABLES. The best procedure is to copy the image from sys$system to a local directory. Then define a logical name (the same as the image name) to tell the command where to find the image (such as DEFINE MACRO32 MYDISK:[MYDIR]MACRO32PATCHED). When changing these offsets in the image header, it is easiest to use PATCH/ABSOLUTE. Then you are dealing with hex offsets 20 and 30.