check/improve compatibility with GnuCOBOL 3.1.1+

[GitMensch]

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.

[OlegKunitsyn]

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);

[GitMensch]

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).

[OlegKunitsyn]

Can you check the master against your test cases? I've tested it on dockerized 3.1.1. and 2.2.

[GitMensch]

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?

[GitMensch]

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.

[OlegKunitsyn]

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?

[GitMensch]

What do you mean by "the GnuCOBOL part"?

[GitMensch]

ping @OlegKunitsyn

[OlegKunitsyn]

I meant GnuCOBOL coverage part. Nevermind.

[GitMensch]

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?

[OlegKunitsyn]

Please confirm that this issue still remains in your test cases since v2.31.32. I can't reproduce.

[GitMensch]

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?

[OlegKunitsyn]

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.

[GitMensch]

I totally agree to keep backwards compatibility. It possibly wasn't that clear what I asked: not remove the mapping code but place it within an `if (!gdb_reports_cobol_already)`