[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] Preliminary results on gdb support
From: |
rasch |
Subject: |
Re: [open-cobol-list] Preliminary results on gdb support |
Date: |
Mon, 15 Jun 2009 11:37:03 +0200 |
User-agent: |
KMail/1.9.5 |
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