Re: [open-cobol-list] Preliminary results on gdb support

[rasch]

Hi, 

this is certainly worth to be continued.

I have two remarks concerning gbd break and gdb step.
Both assume that the generated C source contains line directives 
("#line 123 source.cob").

1. The described method can be used as well to set breakpoints at 
COBOL sections or paragrafs:
Store the paragraf name and the corresponding line number in a
structure in the headerfile. With a gdb macro transform
        (gdb) cobbreak "paragraf name"
to
        (gdb) break coblinenumber

2. To step through COBOL lines, insert a backslash at the end of
each C line between two succesive line directives.
Thus one COBOL line corresponds to one C line.

Hans-Martin Rasch



> Hi,
>
> I have some preliminary results on adding debugging support to OC.
>
> I'd like to get some feedback from the list as to whether it's worth
> pursuing.
>
> This work is based on OC v 1.0. If it's worth continuing, it can't be
> too difficult to port to 1.1
>
> Consider the following COBOL program:
>         PROGRAM-ID.      prog.
>         DATA             DIVISION.
>         WORKING-STORAGE  SECTION.
>         01 G             VALUE "012345678".
>           02 X           PIC X OCCURS 4.
>           02 Z           PIC X OCCURS 1 TO 4.
>         01 H                PIC 99.
>           88 myriad        value 1, 3, 9 thru 16, 17, 25 thru 50.
>         PROCEDURE        DIVISION.
>             DISPLAY X((3 + 1) / 2) NO ADVANCING.
>             DISPLAY X(2 ** 2) NO ADVANCING.
>             DISPLAY Z(1).
>
>             STOP RUN.
>
> Here is a sample run using a simple gdb user-defined command "view" (See
> below)
>
> $ gdb hello
> Breakpoint 1 at 0x8048b5f: file /home/jchimene/hello.cob, line 11. <===
> This breakpoint is set in a project-specific .gdbinit: "break hello.cob:11"
> (gdb) run
>
> Breakpoint 1, prog_ (entry=0) at /home/jchimene/hello.cob:11
> 11                 DISPLAY X((3 + 1) / 2) NO ADVANCING.
>
> (gdb) view "X" <=== Notice the quotation marks
> $1 = (unsigned char *) 0x8049360 "01234567"
>
> (gdb) view "H"
> $2 = (unsigned char *) 0x8049350 "00"
>
> (gdb) quit
>
> The simple way to view COBOL data items is based on the following:
>
> Modify cobc to take the information from the CB_FIELD structure and
> convert it to the following structure:
>
>     static struct symtab {
>          char const         *cobname;
>          unsigned char    *cname;
>     }
>
> This structure is defined and initialized in the program's .h file (e.g.
> hello.c.h)
>
>     static struct symtab {
>          char const         *cobname;
>          unsigned char    *cname;
>     } st[] = { { "X", b_5 }, {"H", b_8}, {'\0'} }
>
> The scope of the variables defined in the .h file is the
> compiler-generated routine "prog_()". This is rather mysterious; there's
> no good way to /a priori/ set COBOL-specific breakpoints [*]. For now,
> it looks like an inspection of the C source combined with a
> project-specific .gdbinit is the solution.
>
> ----------
> [*]
>
>     i.e. a BREAK MAIN produces no useful work as this is the runtime
>     entry point; which is not the same as the start of the procedure
>     division. There doesn't seem to be a good way to always identify the
>     start of the procedure division. I'm probably missing something
> obvious.
>
> The next modification involves a gdb initialization file that searches
> the structure on COBNAME then prints the corresponding CNAME. This
> user-defined command is defined in a project-independent $HOME/.gdbinit
> (or wherever it is for Windows users)
>
>     define view
>          set $r0 = 0
>          set $r1 = st[$r0].cobname
>          while ($r1 > 0)
>              if (0 == strcmp($r1,$arg0))
>                  print st[$r0].cname
>              end
>              set $r0 = $r0 + 1
>              set $r1 = st[$r0].cobname
>          end
>
> The big issue right now is to extend the SYMTAB structure initialization
> to handle the various ways that cobc implements (record definition vs.
> working storage vs. constants) and declares COBOL data items (integer,
> float, &c). The controlling logic is fairly complex, and I don't know if
> duplicating it for the purposes of creating the SYMTAB structure will be
> a useful task.
>
> I've noticed that the cobc switch "-g" does not disable optimization.
> IOW, the "-O2" switch is still sent to gcc. The presence of this switch
> causes the compiler to allocate variables that have the "STATIC" storage
> class in a way that gdb can neither set nor display those variables. OC
> data items have this storage class when they're translated to C. I don't
> know if the combination of "-g" and "-O2" switches is still present in
> OC v1.1 The work-around is to use the cobc "-v" switch to echo the
> command line, then copy and edit the command line to remove the "-O2"
> switch.
>
> ---------------------------------------------------------------------------
>--- Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list

-- 
DSS Incore-Service GmbH
Beethovenstr. 2A
23617 Stockelsdorf
Amtsgericht Lübeck, HRB 1085 BS
Geschäftsführer: Dr. Andreas Longwitz, Josef Flatau