[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 ge

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

On 05/27/2009 09:51 PM, David Essex wrote:
Well DWARF looks interesting, but I'm confused as to your objectives.

Perhaps you could clarify.

I'd love to. Thanks for the opportunity!

The problem statement: "How can I use gdb to examine a COBOL identifier's value and attributes?"

As far as I can tell, the recommended answer to this question is to search the generated C code for the C variable name of a COBOL identifier of interest, then use gdb to examine that C variable at the appropriate time.

I'll stop here if this answer is correct and is the acceptable status quo. I don't see another answer in the FAQ.

I'll stop here if this answer is incorrect.

I'll continue if this answer is correct, and is not the acceptable status quo.

Based on my earlier research into "how do others solve the unsupported language while using gdb issue?", Mono seems to provide an interesting model

What they've done is to leverage gdb/Python integration (nice, but too leading edge) to print formatted dumps of Mono data structures.

I'd like to propose the same thing for OC. gdb supports syntax like:
  • call cob_literal_describe('processing-flag')
  • call cob_identifier_describe('months(1)')
  • call cob_identifier_print('months(2)')
There are at least two ways (and possibly more) to implement such routines:
  • Extend the compiler to produce symbol cross-reference and descriptor information in a private format. Write C routines to read this table at run-time.
  • Extend the compiler to produce symbol cross-reference and descriptor information in Dwarf format. Use libdwarf to produce this file at compile-time and consume this file at run-time. I call this a "shadow" file because it would augment debugging information written by the C compiler. Using libdwarf has the advantage of not reinventing the wheel.
Jeff Chimene wrote:
Would there be any interest in adding an object module generator to 
I'm going to investigate adding support for libdwarf 

Please let me know if this is unsuitable for OC.

The library is copyrighted by Silicon Graphics under the terms of the LPGL.

I'll continue this post once I get some confirmation the libdwarf is 
suitable for inclusion in OC

 From link [1]:
Many projects generate (gcc for example) and consume (gdb for example) 
DWARF2/3 information without any reference-to or use-of libdwarf.

 From link [2]:
The DWARF Debugging Information Format is of interest to programmers 
working on compilers and debuggers.

1) Libdwarf And Dwarfdump

2) David A's DWARF Page

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 as they 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]