2

I was wondering if it is possible to access debug information in a running application that has been compiled with /DEBUG (Pascal and/or C), in order to retrieve information about structures used in the application.

Peter Hofman
  • 673
  • 4
  • 17
  • Can you give some more information what you want to do/achieve? If you compile with /debug, the debug information is in the object module. If you link /debug - usually - the debug information is in the executable. When you just run that executable, the debugger takes over and reads the debug information from the image file into memory. If you run that executable with /nodebug the debug information isn't anywhere in memory. – user2116290 Jan 25 '14 at 10:52
  • For structures, if you want to retrieve the element names (size and offset) you can get that out of the debug information. Been there, did this for ELF/DWARF, but not at run time, I just parsed the DWARF information from the object file. Because OpenVMS/I64 uses ELF and DWARF, almost all of the necessary information is publicly available. For Alpha and VAX there isn't much public information on the debug records. – user2116290 Jan 25 '14 at 11:09
  • What I want to achieve is code generation based on structure information in the debug symbol table. Apparently that has not been done before. I found some example code for using a global symbol, but it did not really help me any further. I also found some code on the freeware CDs for reading symbol tables, but that did not work on my system (7.3-2) after I build it. – Peter Hofman Feb 14 '14 at 08:41
  • After reading the second comment above 'For structure....' by user2116290, I think what I want to achieve is not possible without having the executable read itself en go through the debug records. – Peter Hofman Feb 14 '14 at 08:44

3 Answers3

1

The application can always ask the debugger to do something using SS$_DEBUG. If you send a list of commands that end with GO then the application will continue running after the debugger does its thing. I've used it to dump a bunch of structures formatted neatly without bothering to write the code.

ANALYZE/IMAGE can be used to examine the debugger data in the image file without running the application.

HABO
  • 15,314
  • 5
  • 39
  • 57
  • for sake of completeness, that is "By signalling SS$_DEBUG, for example through a call to LIB$SIGAL." I build this in many programs. It beats an abend with no information. – Hein Jan 25 '14 at 22:43
1

Although you may not see the nice debugger information, you can always look into a running program's data with ANALYZE/SYSTEM .. SET PROCESS ... EXAMINE .... The SDA SEARCH command may come in handy to 'find' recognizable morcels of date, like a record that you know the program must have read. Also check out FORMAT/TYPE=block-type, but to make use of data you'll have to compile your structures into .STB files.

When using SDA, you may want to try run the program yourself interactively in an other session to get sample sample addresses to work from.... easier than a link map! If you programs use RMS a bunch (mine always do :-), then SDA> SHOW PROC/RMS=(FAB,RAB) may give handy addresses for record and key buffers, allthough those may also we managed by the RTL's and thus not be meaningful to you.

Hein
  • 1,453
  • 8
  • 8
  • Regardless of what the OP really wants to do with the debug info, STB (Symbol TaBle) files are generated by the linker, they contain global symbols. The C compiler (and very likely the Pascal compiler as well) does not (and should not) create global symbols for structure elements. Hence their names will not show in the STB. That said, when using SDL (Structure Definition Language) to define the structures and to include the generated output into C (or Pascal) sources, one can also generate MACRO output and let MACRO generate global symbols, which in turn can be used to generate an STB. – user2116290 Jan 26 '14 at 13:52
  • Only on OpenVMS/I64 an STB is equivalent to an object file, so it is sufficient to generate an OBJ file. – user2116290 Jan 26 '14 at 13:53
1

Too long for a comment ...

As far as I know, structure information about elements is not in the global symbol table. What I did, on Linux, but that should work on VMS/ELF files as well:

$ cat tests.c
struct {
        int ii;
        short ss;
        float ff;
        char cc;
        double dd;
        char bb:1;
        void *pp;
} theStruct;
...
$ cc -g -c tests.c
$ ../extruct/extruct 
-e-insarg, supply an ELF object file.
Usage: ../extruct/extruct [OPTION]... elf-file variable
 Display offset and size of members of the named struct/union variable
 extracted from the dwarf info in the elf file.
 Options are:
  -b        bit offsets and bit sizes for all members
  -lLEVEL   display level for nested structures
  -n        only the member names
  -t        print base types
$ ../extruct/extruct -t ./tests.o theStruct
size of theStruct: 0x20
offset size   type name
0x0000 0x0004 int ii
0x0004 0x0002 short int ss
0x0008 0x0004 float ff
0x000c 0x0001 char cc
0x0010 0x0008 double dd
0x0018 0x0001 char bb:1
0x001c 0x0004 pp
$
user2116290
  • 1,062
  • 5
  • 6