Re: Question about getting GNU Cobol work with GDB

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Simon" == Simon Sobisch <simonsobisch@web.de> writes:

Simon> GNU Cobol (formerly OpenCOBOL) translates COBOL to C (compiling
Simon> it with GCC later on).  We try to use GDB as debugging frontend
Simon> but are unsure how some points can be reached without actually
Simon> patching the GDB (if it's possible at all).

Simon> - let the programmer see only the COBOL source, not the C source,
Simon> while stepping

I agree with the other poster who suggested #line.

Simon> - let the programmer view/change/... COBOL variables (there is a
Simon> mapping like you can see above)

I don't think this is doable with your current translation approach.

The simplest way to get this information into gdb is to write out DWARF
from your compiler.  DWARF lets you specify the names of variables and
where they live.

However, I think there's no good way to write out DWARF in the C code
your front end generates.  *Maybe* it can be done in a gross way by
emitting lots of 'asm' statements, but I am not sure whether this can be
made to work without a lot of exertion.

This sort of thing is one reason that it is generally better to write a
GCC front end than to write a translator.  This is easier than it
sounds, but of course you probably have reasons for wanting to do C
translation.

At that point you'll want to write the gdb language support...

Simon> - set breakpoints within the COBOL source

I think #line may help here as well, at least for "file:line"
breakpoints.

I don't remember enough COBOL to know whether there are named
procedures.  If there are then those will face the same conceptual
problem as variables: if the COBOL->C name mapping requires some
transformation, then users won't have a way to use to the name from
their COBOL source.

Tom