Re: [Bug-GnuCOBOL] Debugger.

[Simon Sobisch]

> Just an FYI.
> The READY TRACE features ( some updates in the reportwriter branch)
> can also be useful for debugging COBOL applications.

The trace features are in 2.0 branch, too and the updates in
reportwriter to these are among the things I try to merge in before the
2.2 release.

> Or the old fashion way of inserting DISPLAY statements until your find
> the bug and then remove them later.

... or use debugging lines and activate them via the source header or
via command line option. This way you don't need to remove the lines but
simply can disable them by recompilation, same possible with using the
COBOL 2002+ compiler defines and code
    >> IF DEFINED DEBUG
       DISPLAY stuff
    >>

But a real debugger is often much better for following the program flow,
set breakpoints investigate variables without the need to add the
DISPLAY, recompile, try to get to the same point in execution just to
find another var that you want to see - and ideally it allows you to
change values of variables during the debugging and even change the
program flow directly by skipping parts.

The only *working* option for this source level debugging is to use the
C debugger - where you don't see the COBOL code directly (you have to
view it in a second window) and need to know some internals of GnuCOBOL
to be effective.

And actually all this is the reason for the debugger branch - you can do
without but you could do much more efficient with it...
Volunteers welcome...

Simon

Am 08.05.2017 um 20:50 schrieb Ron Norman:
> 
> 
> On Mon, May 8, 2017 at 2:45 PM, Simon Sobisch <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     3.0 release is planned for end of this year, but this heavily depends on
>     the number of issues found, the number of developers and the number of
>     people that taking care for people's question.
>     As there is no full-time developer for GnuCOBOL yet (no one offered this
>     until now, there was a project specific option but we missed it out, 2.0
>     not available as a release on this time was at least one of the
>     reasons).
>     If all stays as it is now 3.0 may need until April 2018...
> 
>     If SPLIT KEYs are a must (which I can understand - it is possible to do
>     this in COBOL with additional computed fields and my employer did this
>     when we converted our applications to OpenCOBOL 0.something so I could
>     be of help) then use reportwriter branch and consider moving to the
>     development branch once SPLIT KEYs and SPARSE KEYs are merged. As soon
>     as this happens these features get in the debugger branch (or, if
>     someone helps with fixing the issues of the debugger branch in the
>     meantime it will be available in development branch, too).
> 
>     The main focus for now is the 2.2 release candidate, it should be out
>     since end of April 2017...
> 
>     Am 08.05.2017 um 20:31 schrieb studiok:
>     > Any idea about 3.0 release's date?
>     >
>     > Split keys are my must.
>     >
>     > If gc-debugger does not handle them, i'm afraid I'all have to
>     pospose my
>     > intention of working on it.
>     >
>     > In the while, i'll go and read the TODO.
>     >
>     > Marcello
>     >
>     >
>     > Il 08/05/2017 19:18, Simon Sobisch ha scritto:
>     >> Split keys are only supported in reportwriter and will be
>     available in
>     >> the 3.0 release.
>     >>
>     >> For the other program: if you provide a minimal sample raising this
>     >> issue I could check if I can fix the code generation that doesn't
>     work
>     >> worth this sample.
>     >> For known issues with the not-yet-stable debugger branch see the TODO
>     >> file (you may find your issue listed there)
>     >>
>     >> Simon
>     >>
>     >> Am 8. Mai 2017 13:30:22 MESZ schrieb studiok
>     <address@hidden <mailto:address@hidden>>:
>     >>
>     >>     Hello Simon,
>     >>
>     >>     first test:
>     >>
>     >>          cobc  -anim   my-first-test-source.cbl   informs that
>     SPLIT KEYS
>     >>     are not supported (reportwriter and official releas do).
>     >>
>     >>          cobc -anim    my-second-test-source.cbl returns:
>     >>
>     >>     /tmp/cob1758_0.c:348:4: note: previous definition of
>     ‘l_anim_1’ was here
>     >>          l_anim_1:;
>     >>          ^
>     >>     /tmp/cob1758_0.c:506:4: error: duplicate label ‘l_anim_2’
>     >>          l_anim_2:;
>     >>          ^
>     >>
>     >>     How should I go on?
>     >>
>     >>     Thanks,
>     >>
>     >>     Marcello Marsile
>     >>
>     >
> 
> 
> 
> 
> -- 
> Cheers
> Ron Norman