Debugging on X86 (without compiler listings)
Posted: Fri Nov 11, 2022 4:29 pm
A pointer to documentation regarding debugging specifically for X86 would be useful.
This is V9.2. With no native compilers, the XTOOLS C compiler /LIST /MACHINE producing a glorified source listing and no code listing, is there an approach for matching up an X86 LINK /MAP module location? For example, with the following fatal error
I would go to the LINK map and find the module containing the above address
In this case, 8014A19F is between start of module 80141780 and end of module 8014E4E6,.
Use the offset 8014A19F - 80141780 to indicate the module code address, in this case 8A1F.
Find that address in the compiler /MACHINE listing.
Use the line number cross reference to zoom back into the source listing.
(I have a tool that essentially does these steps.)
Without compiler machine code listings this obviously can't be done.
What am I missing? (apart from machine code listings)
What can be done when the software is not amenable to the OpenVMS Debugger?
Process dumps and ANALYZE /PROCESS have nothing to offer
possibly because of the
snipped from the above ACCVIO example.
Any suggestions gratefully considered.
This is V9.2. With no native compilers, the XTOOLS C compiler /LIST /MACHINE producing a glorified source listing and no code listing, is there an approach for matching up an X86 LINK /MAP module location? For example, with the following fatal error
Code: Select all
%SYSTEM-F-ACCVIO, access violation, reason mask=07, virtual address=000000000374C000, PC=FFFF830007A1B0BC, PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000007
000000000374C000
FFFF830007A1B0BC
000000000000001B
Register dump:
RAX = 00000000036724CB RDI = 00000000036724CB RSI = 00000000FFFFFFFF
RDX = 0000000000000000 RCX = 00000000000D9B30 R8 = 000000000367163C
R9 = 000000000013C900 RBX = 000000000000001B RBP = 000000007AD06080
R10 = 000000007AD06310 R11 = FFFFFFFF89C04516 R12 = 00000000207F12A7
R13 = 0000000000000018 R14 = 000000007AD062F0 R15 = 0000000000000000
RIP = FFFF830007A1B0BC RSP = 000000007AD06028 SS = 000000000000001B
8< snip 8<
%HTTPD-F-EXIT, 11-NOV-2022 12:24:40, WASD:80 %X1000000C
-HTTPD-F-TRACE, FFFF830005F96445
-HTTPD-F-TRACE, FFFF8300066D776F
-HTTPD-F-TRACE, FFFF8300066D6152
-HTTPD-F-TRACE, FFFF830005F96445
-HTTPD-F-TRACE, FFFF8300062D2722
-HTTPD-F-TRACE, FFFF8300062D2CDF
-HTTPD-F-TRACE, FFFF83000617CE78
-HTTPD-F-TRACE, FFFF830006187515
-HTTPD-F-TRACE, FFFF830007A1B0BC
-HTTPD-F-TRACE, 000000008014A19F <<<------- this one would be an obvious candidate
-HTTPD-F-TRACE, FFFF830006364711
-HTTPD-F-TRACE, FFFF830006304FFB
-HTTPD-F-TRACE, 000000008018C8B8
-HTTPD-F-TRACE, 000000008018CA79
-HTTPD-F-TRACE, FFFF830007CA3711
-HTTPD-F-TRACE, FFFF830007C58361
Code: Select all
$CODE$ Q-00000000 00000000 00000000 OCTA 4 CON,REL,LCL, SHR, EXE,NOWRT,NOVEC, MOD
80000000 80441925 00441926 ( 4462886.)
8< snip 8<
FILE Q-00000000 00000000 00000000 OCTA 4
80141780 8014E4E6 0000CD67 ( 52583.)
Use the offset 8014A19F - 80141780 to indicate the module code address, in this case 8A1F.
Find that address in the compiler /MACHINE listing.
Use the line number cross reference to zoom back into the source listing.
(I have a tool that essentially does these steps.)
Without compiler machine code listings this obviously can't be done.
What am I missing? (apart from machine code listings)
What can be done when the software is not amenable to the OpenVMS Debugger?
Process dumps and ANALYZE /PROCESS have nothing to offer
Code: Select all
X86VMS$ ana /proc WASD_ROOT:[http$server]HTTPD_SSL.DMP
OpenVMS x86-64 Debug64 Version V9.2-001
%DEBUG-E-ANPKERNOTAVAIL, analyze process dump kernel of the VMS debugger not available
DBG> show process
%DEBUG-W-NOPROCDEBUG, there are currently no processes being debugged
DBG>
Code: Select all
%PROCDUMP-W-BADLOGIC, internal logic error detected at PC 00000000.7B4F2A81
-PROCDUMP-E-NOREAD, no access to location 00000000.00177280, length 00000000.00000098
-PROCDUMP-E-REQUESTED, requested from PC 00000000.7B4F067C
Any suggestions gratefully considered.