[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: |
Sat, 30 May 2009 09:32:51 -0700 |
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.
- 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, Brian Tiffin, 2009/05/25
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Jeff Chimene, 2009/05/27