COBOLworx issueshttps://gitlab.cobolworx.com/groups/COBOLworx/-/issues2023-08-24T15:20:30Zhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/100Fix COBCD to better handle cobc warning output:2023-08-24T15:20:30ZrdubnerFix COBCD to better handle cobc warning output:@ssobisch describes the problem and suggests a solution:
```
2. the handling of cobc's warning output with mangling the line breaks.
I now see that I've forgot about the easiest and likely most reasonable way to handle this which will a...@ssobisch describes the problem and suggests a solution:
```
2. the handling of cobc's warning output with mangling the line breaks.
I now see that I've forgot about the easiest and likely most reasonable way to handle this which will also make cobcd's and cobc's work easier:
cobc $(all_options_but_output) -E > some-tempfile.i
# and pass stdout/stderr as-is
COBC_GEN_DUMP_COMMENTS=1 \
cobc $(all_options_but_source_and_warnings_and_listing) \
-w -### some-tempfile.i
# as before consume and parse the output, but now without
# checking for warning/note/error
# cobc/gcc as before
This way there's only 1 run with cobc over all sources which won't include codegen, this one can output whatever it wants without breaking cobcd as this only inspects the retrun code; no matter if German umlauts are contained or similar and no matter if cobc changes its output formats.
If there's an error (it will be command line options or COBOL) then cobcd can early exit; otherwise it will call cobc to do codegen only once.
```rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/97Implement CI/CD pipeline2024-01-11T21:45:17ZrdubnerImplement CI/CD pipelineIn spite of Simon's (@ssobisch) repeated requests, I have not implemented CI/CD pipeline processing for commits.
That's because I don't know how.
I am not, at the present time, interested in learning; I just don't have the time.
@jklo...In spite of Simon's (@ssobisch) repeated requests, I have not implemented CI/CD pipeline processing for commits.
That's because I don't know how.
I am not, at the present time, interested in learning; I just don't have the time.
@jklowden does know how, so I'll talk to him about it.James K. LowdenJames K. Lowdenhttps://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/71cprint/p my_table should show all of the entries in my _table, up to the limi...2021-11-04T17:19:25Zrdubnercprint/p my_table should show all of the entries in my _table, up to the limit of "show print elements"To avoid explosions of data, I my thought is to expand only explicitly-named table elements.
For example, for
```
01 grandpa
02 dad
03 my_table OCCURS N times
```
cprint/p grandpa will not expand my_table; it'll just sho...To avoid explosions of data, I my thought is to expand only explicitly-named table elements.
For example, for
```
01 grandpa
02 dad
03 my_table OCCURS N times
```
cprint/p grandpa will not expand my_table; it'll just show the first element
cprint/p my_table will expand my_table's elements.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/67[R] DEFINES indicator on cprint/p doesn't appear in Visual Studio Code2021-10-12T03:13:57Zrdubner[R] DEFINES indicator on cprint/p doesn't appear in Visual Studio CodeIn version 4.28, we introduced a [R] suffix on variable names in the cprint/p hierarchical display. But for now that [R] suffix is suppressed in the BuildHierarchicalTree() display routine for machine mode, because the presence of the b...In version 4.28, we introduced a [R] suffix on variable names in the cprint/p hierarchical display. But for now that [R] suffix is suppressed in the BuildHierarchicalTree() display routine for machine mode, because the presence of the bracket causes VSC to throw the variable away. There is, I believe, a regex expression for valid variable names. That expression could probably be edited to allow the bracketed text through. But for now I am not doing it; it's a bit of a headache to find, and test, and then make sure the double-click on variable value to change that value can still be made to work. I am setting it aside for another time.rdubnerrdubnerhttps://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/gcc-cobol/-/issues/34Strange run-time error message for "too many digits" in floating point number2023-09-06T20:32:08ZTorbjörn LindhStrange run-time error message for "too many digits" in floating point numberTrying to see floating point numbers rounded, I just threw a lot of digits at it.
However, with 40 digits, this generates a strange run-time error, which 38 does not.
(Although, the 38 digits are replicated without rounding error... prob...Trying to see floating point numbers rounded, I just threw a lot of digits at it.
However, with 40 digits, this generates a strange run-time error, which 38 does not.
(Although, the 38 digits are replicated without rounding error... probably because it isn't a fp number at all, but an int128.)
On the other hand, the GNU Cobol error message is also quite un-expected. A quick check of IBM manuals show no obvious limit at 38 digits in a fp constant...
IDENTIFICATION DIVISION.
PROGRAM-ID. bug-display1.
PROCEDURE DIVISION.
DISPLAY 3.141592653589793238462643383279502884197
STOP RUN.
$ make bug-display1
gcobol -g -O3 -o bug-display1 -static bug-display1.cbl
$ ./bug-display1
Trying to raise 10 to 40 as an int128, which we can't do.
The problem is in __gg__power_of_ten.
Aborted
$
$ cobc -x bug-display1.cbl -o bug-display1
bug-display1.cbl:5: error: invalid numeric literal: '3141592653589793238462643383279502 ...'
bug-display1.cbl:5: error: literal length 40 exceeds maximum of 38 digits
$https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/issues/33Wrong line number in syntax error message2023-09-01T23:05:49ZTorbjörn LindhWrong line number in syntax error messageIn some cases, syntax error message refer to the line after the actual error.
In this case, the undeclared variable Foo is used on line 5, but the error message refers to line 6.
IDENTIFICATION DIVISION.
PROGRAM-ID. wrong-...In some cases, syntax error message refer to the line after the actual error.
In this case, the undeclared variable Foo is used on line 5, but the error message refers to line 6.
IDENTIFICATION DIVISION.
PROGRAM-ID. wrong-line-syntax-error.
PROCEDURE DIVISION.
MOVE ZERO TO Foo
DISPLAY "Hello"
STOP RUN.
$ gcobol bug-wrong-line-syntax-error.cbl -o bug-wrong-line-syntax-error
bug-wrong-line-syntax-error.cbl:6: syntax error: symbol 'Foo' not found at 'DISPLAY'
cobol1: error: failed compiling bug-wrong-line-syntax-error.cbl
$https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/issues/32Option for warnings about matching -END missing2023-09-01T19:59:49ZTorbjörn LindhOption for warnings about matching -END missingI think it can be quite useful to have the compiler issue warnings if there is no matching END-.
GNU Cobol has -Wterminator
IBM Enterprise Cobol has RULES ENDPERIOD | NOENDPERIOD
I think I prefer a CLI option, but maybe the RULES is u...I think it can be quite useful to have the compiler issue warnings if there is no matching END-.
GNU Cobol has -Wterminator
IBM Enterprise Cobol has RULES ENDPERIOD | NOENDPERIOD
I think I prefer a CLI option, but maybe the RULES is used in some codehttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/99Revisit patching out cob_nop2023-08-24T15:17:05ZrdubnerRevisit patching out cob_nopAs reported by Chuck Haatvedt, patching out cob_nop is broken on systems other than x86_64, or systems not using the Gnu assembler.
I need to remind myself why patching cob_nop out of the generated assembly language was deemed to be a g...As reported by Chuck Haatvedt, patching out cob_nop is broken on systems other than x86_64, or systems not using the Gnu assembler.
I need to remind myself why patching cob_nop out of the generated assembly language was deemed to be a good idea in the first place.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/95cprint with pointer-variable with resolving address2023-02-21T11:59:07ZSimon Sobischcprint with pointer-variable with resolving addressWhen doing a `cprint` to a pointer variable there is currently no hint where it may point to, even not with `cprint /d`.
Compare:
~~~
(gdb) cp /d PT02-PRGM-PTR-H (PRGM-IDX)
Name: 05 PT02-PRGM-PTR-H/PT02-PRGM-PTR-TAB/PROG(283) [W-...When doing a `cprint` to a pointer variable there is currently no hint where it may point to, even not with `cprint /d`.
Compare:
~~~
(gdb) cp /d PT02-PRGM-PTR-H (PRGM-IDX)
Name: 05 PT02-PRGM-PTR-H/PT02-PRGM-PTR-TAB/PROG(283) [W-S]
OCCURS: min: 1 max: 580
Subscripts: (PRGM-IDX); resolves to (283)
Display: 0x00007fc1651c19a3
Hex: 0x00 0x00 0x7f 0xc1 0x65 0x1c 0x19 0xa3
Field: f_1523
Base: b_1522 ( 0x7fc165a2f320 )
RefOffset: 0
data_offset: 0
TableOffset: 2256
Length: 8
DataLoc: 0x7fc165a2fbf0
Attr: a_70
AttrType: 17 (0x11) NUMERIC_BINARY
AttrDigits: 17
AttrScale: 0
AttrFlags: 0x80 IS_POINTER
Data: (HEX) [ a3 19 1c 65 c1 7f 00 00 ]
Data: (ASCII) "\243\031\034e\301\177\000\000"
~~~
With how this would look like with gdb:
~~~
(gdb) p (char[]*)0x7fc1651c19a3
$11 = (char (*)[]) 0x7fc1651c19a3 <PROG500>
~~~
and
~~~
(gdb) cp /d address of MY-VAR
0x7fc165a30541
(gdb) p (char[]*)0x7fc165a30541
$10 = (char (*)[]) 0x7fc165a30541 <b_1517+1>
~~~
Could we get that info "where does the pointer point to" from GDB and present it to the user?
_Really cool_ would be of course to even resolve the data items, like:
~~~
(gdb) cp MY-POINTER
0x7fc165a30541 <MY-RECORD+1>
~~~
But showing what GDB commonly does would be a worthy update in any case, and help a lot - especially with `PROCEDURE-POINTER`s.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/93allow `cwatch` with `ADDRESS OF`, possibly `LENGTH OF`2023-01-13T10:43:00ZSimon Sobischallow `cwatch` with `ADDRESS OF`, possibly `LENGTH OF`It would be useful to be able to actually `cwatch ADDRESS OF LINKAGE-VAR` (that's some of the rare places where we currently still need to fall back to "C" watching) [similar for `BASED` items].
I _think_ this should be allowed only for ...It would be useful to be able to actually `cwatch ADDRESS OF LINKAGE-VAR` (that's some of the rare places where we currently still need to fall back to "C" watching) [similar for `BASED` items].
I _think_ this should be allowed only for variables in `LINKAGE` or `BASED` - otherwise a code like `ConditionalRaise("Variable {0} has a fixed address {1})"` seems reasonable - and for level 01/77 items, which may be tackled by something like `ConditionalRaise("Variable {0} is level {1}, only ADDRESS OF variables on level 01/77 may be watched)"`.
`LENGTH OF` could also vary and _may_ be useful to watch, but that's a much more seldom case and still can be indirectly done with `cwatch` of all `DEPENDING ON` items, so no need for allowing watching that. One thing to consider here is that the current return "invalid syntax" is not ideal, `ConditionalRaise("LENGTH OF may be watched by cwatch ODO item(s)")`, or similar would be _nice_ (not necessary).https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/92allow `cprint ADDRESS OF`2023-01-13T10:43:10ZSimon Sobischallow `cprint ADDRESS OF``BASED` items and items in `LINKAGE` have a "varying" address. We can already `cprint` those, but not assign them, which should be possible, too.
`cprint ADDRESS OF L-VAR = ADDRESS OF WS-VAR`
`cprint ADDRESS OF L-VAR = NULL``BASED` items and items in `LINKAGE` have a "varying" address. We can already `cprint` those, but not assign them, which should be possible, too.
`cprint ADDRESS OF L-VAR = ADDRESS OF WS-VAR`
`cprint ADDRESS OF L-VAR = NULL`https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/91Use of CobolWatchBreakpoint eliminated because it corrupts memory2023-01-10T17:59:20ZrdubnerUse of CobolWatchBreakpoint eliminated because it corrupts memoryHere is the modified code and the comment I added to CWatchWorker::set_watchpoint
```
if False and GV_GlobalVariables.gdb_version >= 80300:
#
# I have effectively removed this code because I have determin...Here is the modified code and the comment I added to CWatchWorker::set_watchpoint
```
if False and GV_GlobalVariables.gdb_version >= 80300:
#
# I have effectively removed this code because I have determined that it doesn't work
# as intended. For the CWATCH test program compiled with GnuCOBOL 3.1.2, it seems to
# work once, but somehow memory gets corrupted and a second attempt to run through
# the program fails. When compiled with 3.2, the breakpoint appears to be set but
# the trap never occurs, and, again, memory is corrupted.
#
# I saw the corruption with 3.1 by setting a CWATCH and then continuing my way
# through the program (TEST006 is an example) until the inferior completed. A
# subsequent RUN command results in an SIGILL illegal instruction trap. With
# 3.2, the trap never occurs, and the second attempt at RUN results in SIGILL.
#
# Using the gdb.Breakpoint method seems to work. The display isn't as nice, because
# it appears the more complex CobolWatchBreakpoint processing apparently tries to
# find the frame with the relevant COBOL source code, but I don't regard this as
# a problem; the user can always use backtrace to see where in the COBOL source code
# the access was initiated. Dubner, 2022-01-10
#
```https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/88Drop NON_PRINTABLE_CHAR - change to GDB way2023-01-13T10:45:25ZSimon SobischDrop NON_PRINTABLE_CHAR - change to GDB wayI've suggested to use `^` for nonprintable characters before - but in retrospective must say it is better to stay with thte GDB way (one of the reasons are GDB frontends).
So instead of `^` (used one time with the NON_PRINTABLE_CHAR con...I've suggested to use `^` for nonprintable characters before - but in retrospective must say it is better to stay with thte GDB way (one of the reasons are GDB frontends).
So instead of `^` (used one time with the NON_PRINTABLE_CHAR constants, otherwise directly) we should use GDB's escaping, which can be created with `"\\" + oct(byte).zfill(5)[2:]` (for whatever reason `[2:].zfill(3)` does not work correctly)
This has the benefit that one can distinguish nonprintable characters, while keeping the extension to not break because of encoding issues.
Only thing to watch out: `\001´ must be counted as one element for the <repeats> code.
It also has the benefit that GDB frontend may be able to actually show those characters when they aren't printable because of encoding issues.rdubnerrdubnerhttps://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/86idea (for later): add new TUI window(s) to display variables/stack2022-01-03T08:30:01ZSimon Sobischidea (for later): add new TUI window(s) to display variables/stackhttps://sourceware.org/gdb/onlinedocs/gdb/TUI-Windows-In-Python.htmlhttps://sourceware.org/gdb/onlinedocs/gdb/TUI-Windows-In-Python.htmlhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/20setting variables via local-view should use the variable path -> error shown ...2021-12-28T16:56:24ZSimon Sobischsetting variables via local-view should use the variable path -> error shown with optfde01While it seems reasonable to me to try to add this extensions' features to a maintained vsix extension (I'd personally try to do this to the native-debug extension, if it is accepted there) I think it is useful to still fix some outstand...While it seems reasonable to me to try to add this extensions' features to a maintained vsix extension (I'd personally try to do this to the native-debug extension, if it is accepted there) I think it is useful to still fix some outstanding issues, including this one.
It can be seen in the optfde01 sample.
![image](/uploads/617473df249323e88fd0df67fc23615d/image.png)
Currently the assignments just use the name of the variable they are applied on, which will often not work and create a "multiple symbols match" issue. The fix seems to be relative easy: use the full path of the variable (if not known create it when reading in the nodes).rdubnerrdubner