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

[Jeff Chimene]

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
>        IDENTIFICATION   DIVISION.
>        PROGRAM-ID.      prog.
>        DATA             DIVISION.
>        WORKING-STORAGE  SECTION.
>        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.
>
>        PROCEDURE DIVISION.
>        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, f0.data = 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.

Cheers,
jec

> Cheers,
> Brian
>
> On May 23, 2009 08:53:07 pm Jeff Chimene wrote:
>    
> > Hi,
> >
> > Would there be any interest in adding an object module generator to
> > OpenCOBOL?
> >
> > ---------------------------------------------------------------------------
> >      
>
>
>
> ------------------------------------------------------------------------------
> 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. http://www.creativitycat.com
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>