[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module g

From: Jeff Chimene
Subject: Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator
Date: Mon, 25 May 2009 18:33:20 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20081105 Thunderbird/ Mnenhy/

On 05/25/2009 04:34 PM, Brian Tiffin wrote:
... And with the rest of the thread upto the note about no gdb COBOL mode. ...

These types of efforts would be greatly appreciated.  The current parser.y is
a fair beasty, but cleanly implemented so it's not too too horrible to grok.

I find it quite understandable. That's why I considered only changing the productions. It's obvious that a lot of work went into it.

One of the things I've been (and, the lead developers have taken kicks at this
as well) is modifying codegen.c to emit  #line nnn "file.cob" so that at
least gdb Step sould show current source lines.  This is not as easy as it
sounds.  The system already has source_location tracing but when 1 line of
COBOL emits zero to n lines of C, the internals of gdb Step get confused and
start showing back steps and other oddities.

Honestly, I think this is a non-starter. Language translations are like the secret ballot. Yes, it's nice, but once you want to audit the results, there is a bridge that you simply cannot cross. Another metaphor is that such translations are like trap-door hash functions.

The other issue is that the parsers COBOL name table is not exported to C.
There is an intermediate translation to b_nnn type names for each COBOL
working storage element.  So display has issues as well.  Personally I don't
mind mentally merging the C with the COBOL as there are very nice comments
and source_location tracer rounds in the generated code, but it would be
wonderous if someone with some know-how on gdb could assist getting some form
of object, C trickery or a gbd-mi map created to allow for more human
friendly debugging.

I'd thought briefly about the compiler producing a DWARF file. However, I don't see any way of telling gdb to load a stand-alone DWARF file. More on that in a moment.

I started looking into the potential of creating scripts for gdb-mi (or maybe
even a front-end) that would hide some of the mucky muck from developers and
make it "look like" a full on source level debug.

It's still C code. There's no understanding of level-88 or "occurs depending". For example, the following
       PROGRAM-ID.      prog.
       DATA             DIVISION.
       01 G-1.
        02 G-2          OCCURS 2.
         03 G-3         OCCURS 2.
          04 G-4        OCCURS 2.
           05 G-5       OCCURS 2.
            06 G-6      OCCURS 2.
             07 G-7     OCCURS 2.
              08 G-8    OCCURS 2.
               09 X     PIC X.

       DISPLAY G-3(1,1).

Gets translated to

$ grep -i b_5 fred.*
fred.c:      memset (b_5, 32, 128);
fred.c: cob_new_display (0, 1, 1, (f0.size = 32, = b_5 + 32 * 0 + 64 * 0, f0.attr = &a_1, &f0)); fred.c.h:static unsigned char b_5[128] __attribute__((aligned)); /* G-1 */

I'd love to hear more about what you think we might be able to pull off and if
you are willing, I'd like to offer whatever technical assistance or grunt
lift and carry might be needed to move towards this goal.

(Aside:  I've been tweaking  GPS  the GNAT Programming Studio IDE for use with
OpenCOBOL and Vala and soon ...<insert other embedded systems we now have
access to as callables from OC core; Guile, Lua, js, ummm, Perl, PHP, S-Lang,
SQLite etc>  and if we could fit this into that, well, yayy team).

I just do not see any way for OpenCOBOL to participate as a first-class client of the GNU toolchain. Once the code crosses the species barrier to C from COBOL, I do not see any way to combine C object files with COBOL source code and data structures.

I'll give it some more thought over the next few days, but I'm not sanguine on the outcome.



On May 23, 2009 08:53:07 pm Jeff Chimene wrote:

Would there be any interest in adding an object module generator to


Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers&  brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,&
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA,&  Big Spaceship.
open-cobol-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]