topic Re: LINK /DSF and traceback. in Operating System - OpenVMS

LINK /DSF and traceback.

Bruce Visscher_1 — Wed, 04 May 2005 10:52:32 GMT

I have always been a little confused about the
affect that the LINK /DSF qualifier has on traceback. Specifically, is it not possible to still get module, routine, and line number information in a %TRACE-F-TRACEBACK display if /DSF is used?

Here is an example. Just for fun, I mix languages.

------------------------------- foo.for --------------------------------
PROGRAM FOO
* This isn't a quote it is an apostrophe.
INTEGER BAR
CALL CRASHME
END
------------------------------- foo.for --------------------------------
----------------------------- crashme.cxx ------------------------------
// $Workfile$
//
// $Log$

#ifdef __VMS
#pragma module CRASHME
#endif

extern "C" void CRASHME() {
throw *(int*)0;
}
----------------------------- crashme.cxx ------------------------------
$ fortran/version
HP Fortran V7.6-4120-48DA2
$ cxx/version
Compaq C++ V6.5-021 for OpenVMS Alpha V7.3-1
$ fortran foo/debug=all/noopt
$ cxx crashme/debug=all/noopt
$ cxxlink/traceback foo,crashme
$ run foo
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=0000000000030084, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
foo CRASHME CRASHME 10 0000000000000014 0000000000030084
foo FOO FOO 4 0000000000000044 0000000000030044
foo 0 00000000000238EC 00000000000338EC
0 FFFFFFFF802874D4 FFFFFFFF802874D4
$ cxxlink/traceback/dsf foo,crashme
$ run foo
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=0000000000030084, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
foo 0 0000000000020084 0000000000030084
foo 0 0000000000020044 0000000000030044
foo 0 00000000000238EC 00000000000338EC
0 FFFFFFFF802874D4 FFFFFFFF802874D4

Personally, I think the /DSF qualifier is a great idea, but not if I loose traceback information in production.

Re: LINK /DSF and traceback.

Ian Miller. — Wed, 04 May 2005 10:57:49 GMT

http://h71000.www7.hp.com/doc/73final/4548/4548pro_011.html#index_x_368

Can you post the result of ANAL/IMAGE
(the first few pages see the flags)

Re: LINK /DSF and traceback.

Bruce Visscher_1 — Wed, 04 May 2005 12:11:44 GMT

The first 3 pages of the anal/image report follows. I also tried setting the DBG$IMAGE_DSF_PATH logical name to no avail.

Analyze Image 4-MAY-2005 12:05:06.48 Page 1
$1$DGA1610:[fake.directory.name]foo.EXE;13
ANALYZ A07-04

This is an OpenVMS Alpha image file

IMAGE HEADER

Fixed Header Information

image format major id: 3, minor id: 0
header block count: 2
image type: executable (EIHD$K_EXE)
I/O channel count: default
I/O pagelet count: default
Symbol Vector Virtual Address: %X'00000000'
Symbol Vector Size: 0 bytes
Virtual Memory Block Size: 65536 (BPAGE = 16)
Fixup Section Virtual Address: %X'00060000'
linker flags:
(0) EIHD$V_LNKDEBUG 0
(1) EIHD$V_LNKNOTFR 0
(2) EIHD$V_NOP0BUFS 0
(3) EIHD$V_PICIMG 1
(4) EIHD$V_P0IMAGE 0
(5) EIHD$V_DBGDMT 1
(6) EIHD$V_INISHR 0
(7) EIHD$V_XLATED 0
(8) EIHD$V_BIND_CODE_SEC 0
(9) EIHD$V_BIND_DATA_SEC 0
(10) EIHD$V_MKTHREADS 0
(11) EIHD$V_UPCALLS 0
(12) EIHD$V_OMV_READY 0
(13) EIHD$V_EXT_BIND_SECT 0

Image Activation Information

first transfer address: %X'00000340'
second transfer address: %X'000108D0'
third transfer address: %X'00010000'

Global Symbol Table & Debug Symbol Table Information

debug symbol table VBN: 0, byte count: 0
global symbol table VBN: 0, record count: 0
debug module/psect table VBN: 0, byte count: 0

Image Identification Information

image name: "FOO"
image file identification: " "
image file build identification: ""
link date/time: 4-MAY-2005 12:01:00.36
linker identification: "A13-01"

Patch Information

There are no patches at this time.

Analyze Image 4-MAY-2005 12:05:06.48 Page 2
$1$DGA1610:[fake.directory.name]foo.EXE;13
ANALYZ A07-04

Image Section Descriptors (ISD)

1) image section descriptor (36 bytes)
byte count: 4096
base virtual address: %X'00010000' (P0 space)
page fault cluster size: default
ISD flags:
(0) EISD$V_GBL 0
(1) EISD$V_CRF 1
(2) EISD$V_DZRO 0
(3) EISD$V_WRT 1
(4) EISD$V_INITALCODE 0
(5) EISD$V_BASED 0
(6) EISD$V_FIXUPVEC 0
(7) EISD$V_RESIDENT 0
(8) EISD$V_VECTOR 0
(9) EISD$V_PROTECT 0
(10) EISD$V_LASTCLU 1
(11) EISD$V_EXE 0
(12) EISD$V_NONSHRADR 1
section type: EISD$K_NORMAL
base VBN: 3

2) image section descriptor (36 bytes)
byte count: 512
base virtual address: %X'00020000' (P0 space)
page fault cluster size: default
ISD flags:
(0) EISD$V_GBL 0
(1) EISD$V_CRF 1
(2) EISD$V_DZRO 0
(3) EISD$V_WRT 1
(4) EISD$V_INITALCODE 0
(5) EISD$V_BASED 0
(6) EISD$V_FIXUPVEC 0
(7) EISD$V_RESIDENT 0
(8) EISD$V_VECTOR 0
(9) EISD$V_PROTECT 0
(10) EISD$V_LASTCLU 1
(11) EISD$V_EXE 0
(12) EISD$V_NONSHRADR 0
section type: EISD$K_NORMAL
base VBN: 11

3) image section descriptor (36 bytes)
byte count: 15872
base virtual address: %X'00030000' (P0 space)
page fault cluster size: default
ISD flags:
(0) EISD$V_GBL 0
(1) EISD$V_CRF 0
(2) EISD$V_DZRO 0
(3) EISD$V_WRT 0
(4) EISD$V_INITALCODE 0
(5) EISD$V_BASED 0

Analyze Image 4-MAY-2005 12:05:06.48 Page 3
$1$DGA1610:[fake.directory.name]foo.EXE;13
ANALYZ A07-04

(6) EISD$V_FIXUPVEC 0
(7) EISD$V_RESIDENT 0
(8) EISD$V_VECTOR 0
(9) EISD$V_PROTECT 0
(10) EISD$V_LASTCLU 1
(11) EISD$V_EXE 1
(12) EISD$V_NONSHRADR 0
section type: EISD$K_NORMAL
base VBN: 12

4) image section descriptor (36 bytes)
byte count: 5120
base virtual address: %X'00040000' (P0 space)
page fault cluster size: default
ISD flags:
(0) EISD$V_GBL 0
(1) EISD$V_CRF 0
(2) EISD$V_DZRO 0
(3) EISD$V_WRT 0
(4) EISD$V_INITALCODE 0
(5) EISD$V_BASED 0
(6) EISD$V_FIXUPVEC 0
(7) EISD$V_RESIDENT 0
(8) EISD$V_VECTOR 1
(9) EISD$V_PROTECT 1
(10) EISD$V_LASTCLU 1
(11) EISD$V_EXE 0
(12) EISD$V_NONSHRADR 0
section type: EISD$K_NORMAL
base VBN: 43

5) image section descriptor (36 bytes)
byte count: 512
base virtual address: %X'00050000' (P0 space)
page fault cluster size: default
ISD flags:
(0) EISD$V_GBL 0
(1) EISD$V_CRF 0
(2) EISD$V_DZRO 1
(3) EISD$V_WRT 1
(4) EISD$V_INITALCODE 0
(5) EISD$V_BASED 0
(6) EISD$V_FIXUPVEC 0
(7) EISD$V_RESIDENT 0
(8) EISD$V_VECTOR 0
(9) EISD$V_PROTECT 0
(10) EISD$V_LASTCLU 1
(11) EISD$V_EXE 0
(12) EISD$V_NONSHRADR 0
section type: EISD$K_NORMAL

6) image section descriptor (36 bytes)
byte count: 1024
base virtual address: %X'00060000' (P0 space)
page fault cluster size: default

Re: LINK /DSF and traceback.

Bruce Visscher_1 — Wed, 04 May 2005 12:56:14 GMT

Posting the (entire) ANAL/IMAGE output as an attachment instead. I didn't care for the way it looked in the post.

Re: LINK /DSF and traceback.

Bruce Visscher_1 — Wed, 04 May 2005 13:06:18 GMT

Perhaps more instructive (or not) is running diff against the analyze/image output after CXXLINK'ing with and without /DSF (but with traceback in both cases). Ingoring dates and executable file versions, the only difference is this "hunk".

-------------------------------- 45 -------------------------------------------------------------- 45 -----------------------------
debug symbol table VBN: 0, byte count: 0 | debug symbol table VBN: 55, byte count: 1024
global symbol table VBN: 0, record count: 0 | global symbol table VBN: 0, record count: 0
debug module/psect table VBN: 0, byte count: 0 | debug module/psect table VBN: 57, byte count: 1

Well, yes, that looks awful too, so I'll attach it as well.

Re: LINK /DSF and traceback.

Guy Peleg — Wed, 04 May 2005 22:22:14 GMT

This is a design limitation.

The linker is not distinguishing between
debug records and tbt (traceback) records.
When /DSF is used, debug and tbt records are
being moved to the DSF file hence you get
no traceback in the image.

The work around we use in VMS engineering is
to link the program twice. Once with
traceback and once for the DSF creation.

This problem has been fixed on IA64.

Guy Peleg
Alpha Linker team

Re: LINK /DSF and traceback.

Ian Miller. — Thu, 05 May 2005 04:27:15 GMT

Off topic but - is it just my impression but is Guy Peleg involved in every part of VMS? :-)

(DCL, LMF, Linker, ... and so on)

Re: LINK /DSF and traceback.

Bruce Visscher_1 — Thu, 05 May 2005 10:02:44 GMT

> This is a design limitation.
>
> The linker is not distinguishing between
> debug records and tbt (traceback) records.
> When /DSF is used, debug and tbt records are
> being moved to the DSF file hence you get
> no traceback in the image.

Thanks for the explanation. I guess I was hoping that the traceback
mechanism would try to find the DSF file at run time. Kind of a long
shot I'll admit.

> The work around we use in VMS engineering is
> to link the program twice. Once with
> traceback and once for the DSF creation.

Unfortunately, for me, that almost defeats the purpose of the /DSF qualifier. I was linking twice before, I was hoping to eliminate that by using /DSF.

> This problem has been fixed on IA64.

Now I am curious what the solution is on IA64. [I'll leave this open for a bit in
case Guy wants to answer.]

Re: LINK /DSF and traceback.

Guy Peleg — Thu, 05 May 2005 10:14:47 GMT

Hi Bruce,

Sorry for disappointing you ;-)
I spent a lot of cycles trying to fix
it but so far nothing....I promise to
try again but I can't give you an ETA....

IA64 uses an industry standard image &
debug format (ELF/DWARF from Intel),
that required a completely new linker.

While on the subject of Linker/Traceback,
until recently, if you installed an image
resident, you lost traceback. We modified the linker and the TRACE facility to
provide traceback for images installed
resident. There was also a limit on the size
of the code section - 32MB, we removed this
limitation as well. This is all available
with the latest LINKER and TRACE kits for
V7.3-1.

Guy

Re: LINK /DSF and traceback.

Bruce Visscher_1 — Thu, 05 May 2005 11:57:36 GMT

Thanks again, Guy.

To answer my refute my own remark about the usefulness of /DSF, of course it still can be useful for analyzing crash dumps, so "Once with traceback and once for the DSF creation" does indeed make sense.