[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: |
Tue, 26 May 2009 08:10:49 -0700 |
Hi,
Thanks for those links. That's certainly the approach I'd take if I
was starting from scratch. The biggest hurdle I see is official
incorporation into GCC. Perhaps that's not as big a hurdle as it
seems.
On the debugging side, here is another possible approach. It's
basically the one that's appeared in various guises in this thread:
http://www.mono-project.com/Debugging
Ignoring the JIT stuff, it would seem that cobc is well on the way to
supporting the necesary call-backs as demonstrated by those Python
data dump routines.
Given the wealth of scripting languages supported by OC, it's really a
matter of designing and implementing useful COBRTL routines for them
to call.
COBOL_OC_DUMP is certainly useful.
On Mon, May 25, 2009 at 8:30 PM, David Essex
<address@hidden> wrote:
> Jeff Chimene wrote:
>
>> Since gdb does not understand COBOL, this may be a moot suggestion. It's
>> certainly possible to teach gdb about COBOL, but would the FSF be
>> interested in that?
>
> GDB is part of the GCC (GNU Compiler Collection) tool chain and requires
> debugging information, known as stabs, to functions properly.
>
> Normally a GCC compiler will generate GNU assembler, as an intermidiate
> code, before creating binary objects.
> The debugging information (stabs) are generated in the GNU assembler
> code (about 10X the ASM code) when the '-g' command line option is used
> (ex: gcc -S -g somecode.c).
>
> OC converts COBOL to C, which any C compiler (in theory) should be able
> to compile. So even if you use GCC-C you can only debug the C code.
>
> Some attempts have been made to backtrack (ASM->C->COBOL) with limited
> success. Not an approach I would recommend.
>
> Frankly, in the long run, it would be easier to write the C code to
> convert the OC syntax tree to the GCC-4 syntax tree, and let the GCC
> back-end do all the real work.
> In essence creating a full GCC-COBOL compiler [1][2]. And a good place
> to start would be here [3].
>
>
> Cheers.
>
> 1) COBOL for GCC - 14. Writing a Compiler Front End
> http://cobolforgcc.sourceforge.net/cobol_14.html
> 2) Writing a GCC Front End
> http://www.linuxjournal.com/article/7884
> 3) OpenCOBOL - B-Wiki - GCC-COBOL
> http://www.opencobol.org/modules/bwiki/index.php?GCC-COBOL
>
>
>
> ------------------------------------------------------------------------------
> 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
>
- Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, (continued)
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Jeff Chimene, 2009/05/25
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Brian Tiffin, 2009/05/25
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Jeff Chimene, 2009/05/27