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

[Jeff Chimene]

On Sat, May 30, 2009 at 12:56 AM, David Essex
<address@hidden> wrote:
> Jeff Chimene wrote:
>  > ...
>> The problem statement: "How can I use gdb to examine a COBOL
>> identifier's value and attributes?"
>> ...
>> 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.

> If I understand this method correctly, you are suggesting adding
> debugging information (function calls) to the C code, and syncing it to
> the COBOL code.

Yes. But:
I don't think there's a way (or a need) to handle call frames,
breakpoints or tracepoints. All such are handled at run-time by code
that's emitted by cobc (line number directives) or C (debug symbol
table).

> More or less the way GCC adds debugging information (stabs) to the
> assembler code.

Yes. Instead of stabs, I'm recommending Dwarf. However, it's not clear
that Dwarf's really necessary. I think that a private symbol cross
reference table (COBOL <-> C) that's augmented with COBOL data
attributes (PIC, USAGE, special handling for LEVEL 88) is the minimum
requirement.

> Yes, I think this method could work, in theory.
> However, I think further research would be required to ensure that all
> of COBOL's features (ex: PERFORM statement) would work with this method.

I don't see a way to handle execution trace or such related run-time
actions. The compiler's currently doing the best it can in this
regard. We can provide more support at debug time for data items. I do
think there's a requirement that local variables are correctly
handled. For that reason, Dwarf may have an advantage in that it's
already structured to handle such scope-related issues.

> Certainly no small task, me thinks.

Agreed. That's why I want to spend as much time on analysis and design
before coding. Also, that's why I'm considering using Dwarf.