cbl-gdb issueshttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues2024-01-22T02:24:19Zhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/102FR: new command that shows the location of a variable2024-01-22T02:24:19ZSimon SobischFR: new command that shows the location of a variable.. or at least the place where it is defined, in which case the user can do a follow-up `list some.cpy:53`.
This mimics the command "show definition" in MF animator and other debuggers (the use is to see both the variable definition and..... or at least the place where it is defined, in which case the user can do a follow-up `list some.cpy:53`.
This mimics the command "show definition" in MF animator and other debuggers (the use is to see both the variable definition and its context).
I _guess_ this information would needed to be included in the internal symbol table - or could that be somehow found at runtime?
For adding it into the symbol table this would need additional lookup, most reasonably likely adjustment to `cob_dump_field_ext`, maybe similar to:
```c
P_dump:
{
cob_field f0;
memset(&f0,0,sizeof(f0));
/* Dump WORKING-STORAGE */
cob_dump_output("WORKING-STORAGE");
cob_dump_field_ext ( 1, "ME-EXCH-BASIS", COB_SET_FLD(f0, 3, b_8, &a_3), 0, 0); /* prog.cob:55 */
cob_dump_field_ext ( 5, "ME-X-FX", COB_SET_FLD(f0, 1, b_8, &a_1), 0, 0); /* :56 */
cob_dump_field_ext ( 5, "ME-X-P", COB_SET_FLD(f0, 1, b_8 + 1, &a_1), 0, 0); /* :57 */
cob_dump_field_ext ( 5, "ME-X-C", COB_SET_FLD(f0, 1, b_8 + 2, &a_1), 0, 0); /* :58 */
/* cob_dump_field_ext ( 1, "FILLER", COB_SET_FLD(f0, 3, b_8, &a_1), 0, 0); REDEFINES */ /* :59 */
/* cob_dump_field_ext (88, "SW-EXCH-BASIS-KOMPLETT", COB_SET_FLD(f0, 3, b_8, &a_1), 0, 0); VALUE (cob_field *)&c_3 */ /* :60 */
/* cob_dump_field_ext ( 1, "ME-EXCH-RMS", COB_SET_FLD(f0, 1, b_14, &a_3), 0, 0); */
/* cob_dump_field_ext ( 5, "ME-X-RMS", &f_15, 0, 0); */
/* cob_dump_field_ext ( 1, "FILLER", &f_16, 0, 0); REDEFINES */
/* cob_dump_field_ext (88, "SW-EXCH-RMS-KOMPLETT", &f_16, 0, 0); VALUE (cob_field *)&c_1 OR (cob_field *)&c_4 */
cob_dump_field_ext ( 1, "SOME-VAR", COB_SET_FLD(f19, 3, b_55, &a_3), 0, 0); /* sub1/some.cpy:12 */
}
```
Note: GC3.2 creates `#line` directives to the place where the variables are initialized, but I don't see a direct option how to use that in the python extension.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/96handle compilation from C file2023-07-13T06:45:56ZSimon Sobischhandle compilation from C fileThe following works as expected:
cobcd prog.cob
Using the following should be identical, but does not lead to cobcd doing any adjustments to the generated file
cobcd -C prog.cob
cobcd prog.c
Please provide an option to "force" the ge...The following works as expected:
cobcd prog.cob
Using the following should be identical, but does not lead to cobcd doing any adjustments to the generated file
cobcd -C prog.cob
cobcd prog.c
Please provide an option to "force" the generation of COBOL informations for this case (or better: peek into the C file to "see" if it is COBOL).https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/94support for level 88 / conditionals is missing2024-01-19T15:49:45ZSimon Sobischsupport for level 88 / conditionals is missingI've _thought_ to have raised that before, but sadly this was only posted via mail (October 2021). Therefore I'll quote from that mail - not everything may be up-to-date, but the general issue is still the same (other than GC3.2-rc1 actu...I've _thought_ to have raised that before, but sadly this was only posted via mail (October 2021). Therefore I'll quote from that mail - not everything may be up-to-date, but the general issue is still the same (other than GC3.2-rc1 actually leaving the level 88 informations in the dump code, so cobcd could read those in).
Note, that there's a "quite intense" request of this "missing feature" in cbl-gdb...
Code example:
```cobol
01 ME-EXCH-BASIS.
05 ME-X-FX PIC X(01) VALUE SPACE.
05 ME-X-P PIC X(01) VALUE SPACE.
05 ME-X-C PIC X(01) VALUE SPACE.
01 FILLER REDEFINES ME-EXCH-BASIS PIC X(03).
88 SW-EXCH-BASIS-KOMPLETT VALUE "JJJ", "XXX".
```
The programmer can (early 428) ask for all symbols but SW-EXCH-BASIS-KOMPLETT - the level 88 variable which returns
> No symbol matches "SW-EXCH-RMS-KOMPLETT" in current context
As a comparison, this is what happens with different debuggers:
ACUCOBOL-GT:
d SW-EXCH-RMS-KOMPLETT -> actually prints whatever is at the memory there, so possibly JNJ; that is not "good" but at least allows to easier check manually for true/false
MF SE:
SW-EXCH-RMS-KOMPLETT: False (would print "True" if "JJJ" is in there)
Ideally cobcd would:
```
(gdb) cp ME-EXCH-BASIS="JNJ"
ME-EXCH-BASIS="JNJ"
(gdb) cp SW-EXCH-RMS-KOMPLETT
False ("JNJ")
(gdb) cp SW-EXCH-RMS-KOMPLETT = true # setting the memory to the first TRUE value, but that's optional
True ("JJJ")
(gdb) cp /d SW-EXCH-RMS-KOMPLETT
--> showing all attributes and storage as now, but additional
TRUE: "JJJ", "XXX"
or similar, so showing the values that would display a TRUE value
```
Neither ACU nor MF allow an explicit setting of true/false (which COBOL does), not sure if you want to add that to cobcd (that's totally "optional", you likely want to consider this for gcobol + gdb integration in any case).
The old output of cobc back then:
```c
P_dump:
{
cob_field f0;
memset(&f0,0,sizeof(f0));
/* Dump WORKING-STORAGE */
cob_dump_output("WORKING-STORAGE");
cob_dump_field_ext ( 1, "ME-EXCH-BASIS", COB_SET_FLD(f0, 3, b_8, &a_3), 0, 0);
cob_dump_field_ext ( 5, "ME-X-FX", COB_SET_FLD(f0, 1, b_8, &a_1), 0, 0);
cob_dump_field_ext ( 5, "ME-X-P", COB_SET_FLD(f0, 1, b_8 + 1, &a_1), 0, 0);
cob_dump_field_ext ( 5, "ME-X-C", COB_SET_FLD(f0, 1, b_8 + 2, &a_1), 0, 0);
/* cob_dump_field_ext ( 1, "FILLER", COB_SET_FLD(f0, 3, b_8, &a_1), 0, 0); REDEFINES */
/* cob_dump_field_ext ( 1, "ME-EXCH-RMS", COB_SET_FLD(f0, 1, b_14, &a_3), 0, 0); */
/* cob_dump_field_ext ( 5, "ME-X-RMS", &f_15, 0, 0); */
/* cob_dump_field_ext ( 1, "FILLER", &f_16, 0, 0); REDEFINES */
}
```
... so there's no info there - of course cobcd.py could not do anything.
I've put some time in to add the missing information, which then was generated as follows:
```c
P_dump:
{
cob_field f0;
memset(&f0,0,sizeof(f0));
/* Dump WORKING-STORAGE */
cob_dump_output("WORKING-STORAGE");
cob_dump_field_ext ( 1, "ME-EXCH-BASIS ", COB_SET_FLD(f0, 3, b_8, &a_3), 0, 0);
cob_dump_field_ext ( 5, "ME-X-FX", COB_SET_FLD(f0, 1, b_8, &a_1), 0, 0);
cob_dump_field_ext ( 5, "ME-X-P", COB_SET_FLD(f0, 1, b_8 + 1, &a_1), 0, 0);
cob_dump_field_ext ( 5, "ME-X-C", COB_SET_FLD(f0, 1, b_8 + 2, &a_1), 0, 0);
/* cob_dump_field_ext ( 1, "FILLER", COB_SET_FLD(f0, 3, b_8, &a_1), 0, 0); REDEFINES */
/* cob_dump_field_ext (88, "SW-EXCH-BASIS-KOMPLETT", COB_SET_FLD(f0, 3, b_8, &a_1), 0, 0); VALUE (cob_field *)&c_3 */
/* cob_dump_field_ext ( 1, "ME-EXCH-RMS", COB_SET_FLD(f0, 1, b_14, &a_3), 0, 0); */
/* cob_dump_field_ext ( 5, "ME-X-RMS", &f_15, 0, 0); */
/* cob_dump_field_ext ( 1, "FILLER", &f_16, 0, 0); REDEFINES */
/* cob_dump_field_ext (88, "SW-EXCH-RMS-KOMPLETT", &f_16, 0, 0); VALUE (cob_field *)&c_1 OR (cob_field *)&c_4 */
}
```
As you see the validation fields are in now, pointing to the related memory ("parent" with a new
VALUE constant [OR constant | contant THRU constant]...
generated.
This now shows up in cobcd as expected (because neither cobcd nor cobcd.py know anything about the VALUE stuff):
(gdb) cp SW-EXCH-RMS-KOMPLETT
88 SW-EXCH-RMS-KOMPLETT/FILLER : "J^^^"
(gdb) cp/x SW-EXCH-RMS-KOMPLETT
88 SW-EXCH-RMS-KOMPLETT/FILLER : 0x4a000000
So we already have the ACUCOBOL-GT debugger's behaviour by those changes with GnuCOBOL 3.2 "for free" - it seems that this didn't break anything and everything else still works. Here's the full output:
(gdb) cp *
1 : 01 ME-EXCH-BASIS : " "
2 : 05 ME-X-FX/ME-EXCH-BASIS : " "
3 : 05 ME-X-P/ME-EXCH-BASIS : " "
4 : 05 ME-X-C/ME-EXCH-BASIS : " "
5 : 01 FILLER : " "
6 : 88 SW-EXCH-BASIS-KOMPLETT/FILLER : " "
7 : 01 ME-EXCH-RMS : "J"
8 : 05 ME-X-RMS/ME-EXCH-RMS : "J"
9 : 01 FILLER : "J^^^"
10 : 88 SW-EXCH-RMS-KOMPLETT/FILLER : "J^^^"
For users this will obviously mean a bit longer compile times and an even bigger `VARIABLE_STRING` (static read-only data), but fixing the unknown symbols is worth it.
Can you please adjust at least cobcd to read in the additional VALUE information? As expected those aren't in:
```
(gdb) with print elements unlimited -- print VARIABLE_STRING_MDCFS202Ecob
$2 = "000000496P||MDCFS20|/tmp/MDCFS20.cob|||24||||~E||MDCFS20|/tmp/MDCFS20.cob|||24||||~W|1|ME-EXCH-BASIS||b_8|a_3||3|||~W|5|ME-X-FX||b_8|a_1||1|||~W|5|ME-X-P||b_8|a_1|1|1|||~W|5|ME-X-C||b_8|a_1|2|1|||~W|1|FILLER||b_8|a_1||3|||~W|88|SW-EXCH-BASIS-KOMPLETT||b_8|a_1||3|||~W|1|ME-EXCH-RMS||b_14|a_3||1|||~W|5|ME-X-RMS|f_15|b_14|a_1||1|||~W|1|FILLER|f_16|b_14|a_1||4|||~W|88|SW-EXCH-RMS-KOMPLETT|f_16|b_14|a_1||4|||~"
```
Note: the list of VALUE consist often of 1 entry, but it may also be hundred entries with OR and possibly also some combined with THRU.
Of course integrating them in VARIABLE_STRING is only useful if you intend to provide the MF Animator feature of printing True/False someday, ideally with the cobcd.py feature of showing the actually validated variable content in parens.
Even if you don't do this for the next release in the python side - please consider it for cobcd - because shipping an updated cobcd.py is easy, installing cobcd and recompiling everything isn't...
Side note: adjustment to handle these a bit better in cobcd.py:
in `ProcessArguments()`:
```diff
payload = GV_ModuleInformation.var_trie.storage_list[index]
+ if payload.level == 88:
+ ConditionalRaise("a conditional variable (level 88) may not be used as source")
+ return
```
in `set_var_value()`:
```diff
var_left = GV_GlobalVariables.VarLeft
+ if var_left.level == 88:
+ ConditionalRaise("a conditional variable (level 88) may not be set directly")
+ # note: should be done later via = true/false
+ return 0
```rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/90code generation broken ... at least for aarch64-clang2023-01-16T20:27:50ZSimon Sobischcode generation broken ... at least for aarch64-clangAll tests fail, here's number 2
~~~
test.s:10411:1: error: unassigned file number: 1 for .file directives
^
test.s:10411:1: error: unassigned file number: 2 for .file directives
^
test.s:10411:1: error: unassigned file number: 4 for ....All tests fail, here's number 2
~~~
test.s:10411:1: error: unassigned file number: 1 for .file directives
^
test.s:10411:1: error: unassigned file number: 2 for .file directives
^
test.s:10411:1: error: unassigned file number: 4 for .file directives
^
test.s:10411:1: error: unassigned file number: 5 for .file directives
^
make: *** [Makefile:36: test] Error 1
~~~
And indeed, the generated file does look suspicious:
```asm
.file "test.cbl"
.file 3 "/data/data/com.termux/files"
.file 6 "/data/data/com.termux/files/home/cbl-gdb/tests/test002"
.globl main // -- Begin function main
.p2align 2
.type main,@function
main: // @main
.loc 6 127
.Lfunc_begin0:
.cfi_startproc
// %bb.0:
```
And the reason for this is possibly that the generated file entries that cobcd gets are quite strange:
```asm
.file "test.c"
.file 1 "/data/data/com.termux/files/home/cbl-gdb/tests/test002" "./test.c.l.h"
.file 2 "/data/data/com.termux/files" "usr/include/libcob/common.h"
.file 3 "/data/data/com.termux/files" "usr/lib/clang/15.0.6/include/stddef.h"
.file 4 "/data/data/com.termux/files/home/cbl-gdb/tests/test002" "test.c"
.file 5 "/data/data/com.termux/files/home/cbl-gdb/tests/test002" "./test.c.h"
---
.file 6 "/data/data/com.termux/files/home/cbl-gdb/tests/test002" "test.cbl"
```
So the issues are:
* strangely there may be a space between the folder and the "file" -> cobcd should copy the file entries until end of line
* some assemblers error on missing file numbers, if cobcd just "drops" the "bad" C ones, then it should renumber the entries instead (keeping the order)
[test.adjusted.c](/uploads/3c650c26a8928a5bd734d5eba44dc336/test.c)
[test.original.s](/uploads/87db78a5325d04ef28e24f2bc8368ac2/test.original.s)
[test.adjusted.s](/uploads/bde4ae6060b8604a6e9d5cfaac8555e9/test.adjusted.s)https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/87cobcd: handling keyboard interrupt2022-01-03T08:32:16ZSimon Sobischcobcd: handling keyboard interruptWhen pressing CTRL+C during a compilation we currently get a stacktrace "Something went wrong with the command ... KeyboardInterrupt".
This special case should be explicit catched (similar as it is done in cobcd.py), and internally abort...When pressing CTRL+C during a compilation we currently get a stacktrace "Something went wrong with the command ... KeyboardInterrupt".
This special case should be explicit catched (similar as it is done in cobcd.py), and internally abort the compilation without a python stacktrace.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/46missing error message if cobc is not available2021-07-22T11:48:26ZSimon Sobischmissing error message if cobc is not availableI need to check if that still happens with a newer version, at least 4.10 had this "issue":
`cobcd -V` outputs its version, and then exits with return code 1.
Expected: a message in stderr, possibly similar to bash: `cobc: command not ...I need to check if that still happens with a newer version, at least 4.10 had this "issue":
`cobcd -V` outputs its version, and then exits with return code 1.
Expected: a message in stderr, possibly similar to bash: `cobc: command not found`rdubnerrdubner