[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

388.0. "Overlapping image address space debug problem?" by KSTREL::PEARSON () Wed Mar 26 1997 16:31

We have an image, ACMSACC.EXE which is linked with a couple of shared
images.  On Alpha, two of the images have overlapping address space
according to SDA.  The following was done on VMS 7.1, but the problem is
also on 6.1.  I haven't checked on 6.2.

Process index: 011A   Name: ACMS01ACC001000   Extended PID: 2F40491A
--------------------------------------------------------------------


                            Process activated images
			    ------------------------

IMCB    Start     End    Sym Vect    Type      Image Name  Major ID,Minor ID
-------- -------- -------- -------- ------------ -----------------------------
7FF6A620 00010000 000809FF 00000000 MAIN         ACMSACC 0,0
7FF685C8 00082000 0029AC98 001C2000 GLBL PRT SHR ACMSHR 7,100
7FF6A460 00238000 002983FF 002386F0 GLBL     SHR ACMS$TRACE_SHR 1,1000


The remainder of the display appears to be irrelevant.  At least to me it
is.  As you can see, the images ACMSHR and ACMS$TRACE_SHR have overlapping
addresses.  The program runs fine, but trying to debug ACMS$TRACE_SHR is an
incredible pain.  When you try to step through code in ACMS$TRACE_SHR, the
debugger thinks that it is in the image ACMSHR.  I presume that this
problem is related to the overlapping address space.

Is this a known problem or is the ACMS group the only one to suffer with
this one?

Larry Pearson

T.R	Title	User	Personal Name	Date	Lines
388.1	Questions...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed Mar 26 1997 16:51`	6
	How are these images linked? Are there writeable images (COMMONs) involved? Are there any link errors or based-image messages? Is anyone using LIB$FIND_IMAGE_SYMBOL? What are the attributes for the various images and image sections from the link map?
388.2		EEMELI::MOSER	Orienteers do it in the bush...	`Thu Mar 27 1997 06:29`	5
	I've seen that too with ACMS over a year ago. It's the way they link their stuff together. Things do work correctly I've verified that and this is just an annoying bystander issue. /cmos
388.3	Answers to .1	KSTREL::PEARSON		`Thu Mar 27 1997 11:11`	24
	RE: 388.1 There are writable PSECTs, but none of them are shared. They are debug images and they're installed. The code PSECTs are set writable so that breakpoints can be set. We also understand the implications of writable code psects in shared images. We do debugging on individual workstations. They are not based images and there are no link errors. LIB$FIND_ImAGE_SYMBOL is used, but not for either of these two images. I've extracted the link information for ACMSHR.EXE and ACMS$TRACE_SHR.EXE in .LOG files with the same file name. The MAP files are also available in the same location on the node CLUSTA. Directory CLUSTA::ACMS$PUBLIC ACMS$TRACE_SHR.LOG;1 3 27-MAR-1997 10:55:50.20 ACMS$TRACE_SHR.MAP;7 55 24-MAR-1997 15:29:56.14 ACMSHR.LOG;1 90 27-MAR-1997 11:06:01.80 ACMSHR.MAP;1 2483 23-FEB-1997 00:36:34.25 Total of 4 files, 2631 blocks. Larry Pearson
388.4	Looks Like Self-Modifying Code...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Mar 27 1997 11:21`	16
	My assumption is that you effectively have a COMMON, and I've found COMMONs cause all manner of "interesting" maintenance and debugging implications. And headaches. I'd use a different technique to create the debugging structure(s). I'd look at imbedding the debugging code calls directly into the image, or using conditional compilations, or using stub shareable images, or run-time LIB$FIND_IMAGE_SYMBOL calls, or using a "patchable vector array table" that can be built at run-time or revectored at run-time via a global section, etc. Or some combination. Using writable code is definitely questionable. If this technique is used, there are specific cache-flushing requirements for what is effectively better known as "dirty" or "self-modifying" code.