- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- LINK /DSF and traceback.
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 03:52 AM
тАО05-04-2005 03:52 AM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 03:57 AM
тАО05-04-2005 03:57 AM
Re: LINK /DSF and traceback.
Can you post the result of ANAL/IMAGE
(the first few pages see the flags)
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 05:11 AM
тАО05-04-2005 05:11 AM
Re: LINK /DSF and traceback.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 05:56 AM
тАО05-04-2005 05:56 AM
Re: LINK /DSF and traceback.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 06:06 AM
тАО05-04-2005 06:06 AM
Re: LINK /DSF and traceback.
-------------------------------- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 03:22 PM
тАО05-04-2005 03:22 PM
Re: LINK /DSF and traceback.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2005 09:27 PM
тАО05-04-2005 09:27 PM
Re: LINK /DSF and traceback.
(DCL, LMF, Linker, ... and so on)
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2005 03:02 AM
тАО05-05-2005 03:02 AM
Re: LINK /DSF and traceback.
>
> 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.]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2005 03:14 AM
тАО05-05-2005 03:14 AM
SolutionSorry 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2005 04:57 AM
тАО05-05-2005 04:57 AM
Re: LINK /DSF and traceback.
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.