check/improve compatibility with GnuCOBOL 3.1.1+
Opened this issue · 14 comments
I've tested the most recent version with Arnold Trembley's 3.1.1-package and stepping did not work correctly.
Tested program: NC104A.CBL
I only removed -free (I "may" have mentioned that I think neither the in-debug-auto-"task-step" compile nor the default of -free seems useful to me) and left all other settings at default.
The debugging starts correctly, variables look fine, the stepping works only partially (often skips multiple lines).
Note: 3.1.1 has a quite different codegen, and if not explicit asked for also generated COBOL line comments (so GDB already does know which COBOL line it operates on) - so if it works as expected on non-win32 it seems reasonable to still adjust the part that tries to match COBOL and C lines.
For improved field knowledge with (and especially without) -fdump #92 may also be useful.
How can I instruct GC to remove intermediate comment lines?
before
/* Line: 7 : MOVE : /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl */
cob_set_location (st_1, 7, NULL, NULL, st_5);
memcpy (b_6, "World", 5);
now
/* Line: 7 : MOVE : /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl */
#line 7 "/home/olegs/projects/gnucobol-debug/test/resources/hello.cbl"
cob_trace_stmt (st_2);
#line 116 "hello.c"
memcpy (b_8, "World", 5);
That are no comment lines but instructions (ending up in the final binary) about the positions.
I suggest to take the benefit of these (ideally the plugin never has to "know"/"calculate"/"fake" the COBOL line number - GDB has that already, just "hide" the C part.
If this is really not possible then those directives may be removed by -fno-gen-c-line-directives (that switch is auto-activated with -g, along with the -fgen-c-labels which allow to set breakpoints on every ENTRY and SECTION, a feature that may be made more user-friendly with this plugin, too).
Can you check the master against your test cases? I've tested it on dockerized 3.1.1. and 2.2.
I'd but I've not dived into extension writing or even compiling yet, so you'd have to upload your vsix, possibly here.
Theoretically we should be able to create a CI to do so for every commit (hm, we already have #71 for that).
Do you think this extension could benefit of the info GDB has with "knowing" the COBOL source and line later`and not match the lines for 3.1.1+ itself? Should I open a new issue for that?
Note: if you take the NIST-test sample given in the issue's start post and check that it works with containerized 3.1.1 then that's fine and I'd consider it worthy for a new release.
launch.json: "docker": "olegkunitsyn/gnucobol:2.2" generates coverage for C
command line: cobc -free -x -g -fsource-location -ftraceall -Q --coverage -A --coverage -v /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl
preprocessing: /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl -> hello.i
parsing: hello.i (/home/olegs/projects/gnucobol-debug/test/resources/hello.cbl)
translating: hello.i -> hello.c (/home/olegs/projects/gnucobol-debug/test/resources/hello.cbl)
executing: gcc -c -I/usr/local/include -Wno-unused -fsigned-char
-Wno-pointer-sign -pipe -g --coverage -o "/tmp/cob7_0.o"
"hello.c"
executing: gcc -Wl,--export-dynamic -o "hello" "/tmp/cob7_0.o" --coverage
-L/usr/local/lib -lcob -lm -lgmp -lintl -lncurses -ldb-5.3
launch.json: "docker": "olegkunitsyn/gnucobol:3.1" generates coverage for C and GnuCOBOL
command line: cobc -free -x -g -fsource-location -ftraceall -Q --coverage -A --coverage -v /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl
preprocessing: /home/olegs/projects/gnucobol-debug/test/resources/hello.cbl -> hello.i
parsing: hello.i (/home/olegs/projects/gnucobol-debug/test/resources/hello.cbl)
translating: hello.i -> hello.c (/home/olegs/projects/gnucobol-debug/test/resources/hello.cbl)
executing: gcc -c -pipe -I/usr/local/include -Wno-unused -fsigned-char
-Wno-pointer-sign -ggdb3 -fasynchronous-unwind-tables
--coverage -o "/tmp/cob7_0.o" "hello.c"
executing: gcc -Wl,--export-dynamic -o "hello" "/tmp/cob7_0.o" --coverage
-L/usr/local/lib -lcob -lm
How can I disable GnuCOBOL part via the command line?
What do you mean by "the GnuCOBOL part"?
ping @OlegKunitsyn
I meant GnuCOBOL coverage part. Nevermind.
Note: 3.1+ has a quite different codegen, and if not explicit asked for also generated COBOL line comments (so GDB already does know which COBOL line it operates on) [...]-it seems reasonable to still adjust the part that tries to match COBOL and C lines.
What I meant here: do we need the internal match at all with an up-to-date version or could this be "deactivated" in this case?
Should I open a new issue for that?
Please confirm that this issue still remains in your test cases since v2.31.32. I can't reproduce.
Please confirm that this issue still remains in your test cases since v2.31.32. I can't reproduce.
The issue "it doesn't work" is not reproducible any more.
What I meant here: do we need the internal match at all with an up-to-date version or could this be "deactivated" in this case?
Should I open a new issue for that?
The question is: can we disable the recalculation "COBOL source line X C source line Y" if we see COBOL line numbers? This would have the benefit that we need less parsing of the C source (it is still needed because of the fields matching, but I hope to resolve that later from the GnuCOBOL side).
GDB already knows of the COBOL line numbers if we compile with -g under GC 3.1.2 - does this extension needs to know more?
If the variables, stepping and coverage were fixed (for me, yes) then I see no reason to keep this issue open.
I'll keep backward compatibility with 2.2 without disabling of the mapping.