Support for USAGE
brunopacheco1 opened this issue · 15 comments
Moving to this issue the topic of supporting extra complex data types provided by GC.
In order to support USAGE, like in the piece of code below, we will need to have in the libcob functions to abstract the internal GC complexities, so no extra parsing will be required to do in the extension.
05 bin-u usage binary pic 99v999 value 12.34.
05 cmp3 usage packed-decimal pic s99v999 value -12.34.
05 cmp3-u usage packed-decimal pic 99v999 value 12.34.
05 cmp5 usage comp-5 pic s99v999 value -12.34.
05 cmp5-u usage comp-5 pic 99v999 value 12.34.
05 cmp6 usage comp-6 pic 99v999 value 12.34.
Two feature requests were open in the GC repository: Printing Cob Field Values and Setting Cob Field Values;
As soon as we have these features integrated into the libcob, we will be able to fully support USAGE in the extension.
Remarks: We cannot forget to check the GC version to choose the correct commands when evaluating variables.
GC functions available with GnuCOBOL 3.1-rc1, implemented in revision 3670.
Have fun! I'm so keen to see how they work out as many things including remote debugging are related to this, too.
Remarks: We cannot forget to check the GC version to choose the correct commands when evaluating variables.
Please don't go the version check route - instead ask gdb about the additional functions and if available use them, if not I suggest to only support USAGE DISPLAY in direct input/output and only show hex values for all others.
Please don't go the version check route - instead ask gdb about the additional functions and if available use them
Great, thanks for the suggestion.
@OlegKunitsyn It'd be nice if you release a new docker image with the new GC version.
Hallo!
So, USAGE support is back, thanks to @GitMensch we have those functions to get and set cob_field values as string.
Even though the function cob_put_field_str() is working correctly when it's called on GDB, I cannot test setting variable values through VSCode. I believe it's either a cobol-debug's defect or it's a limitation of the Language Support for COBOL (I am using the bitlang COBOL extension).
Apart from that, I believe this issue is almost done.
Yay - and somehow I think this is better than it ever was ;-)
And actually #40 looks to be nearly finished, too (69814e4 seems to reference the wrong issue).
Indeed, I had double thoughts about tackling it here or not, but actually the feature of setting variable value was always there (even apparently not working), what I did was adding the call to cob_put_field_str() which is part of supporting USAGE, I think at least.
Yay - and somehow I think this is better than it ever was ;-)
It is faster and cleaner in so many ways, and look at this Debug Console.
Sounds like time for PR and close of this issue in favor of a possible new issue "Support for USAGE with old GnuCOBOL versions".
While this new issue wouldn't have any priority for me [I'm mostly interested in the use of "current"] it would be some place to track this and also possibly explain to people why they may see different/no values when using an older system-repository version of GnuCOBOL [or maybe even OpenCOBOL 1.1, has anyone checked if this works somehow?].
... and a release for people to be able to use this and whatever we have for #3.
Closing this issue as the changes were merged into the master.
@OlegKunitsyn I closed this issue, but now I saw the changes were not released. Could you review the changes and do a release?
Well done, @brunopacheco1! Yes, it's there.
I'm expecting a very strange result with gnucobol-debug 1.31.24 and GC-3.1-rc1 (Arnold's build):
- compilation part of the debugging works (I'm always confused that nothing happens, until I toggle both the verbose mode to true and manually open the debug pane which is very confusing but tracked at #26 already; then recognize that the default was "free" [which I still consider a bad default giving most code being in fixed format and free-format can be annotated in code via compiler directive], then removing it)
- stepping and display works
- all level 01 items are "recognized" as "group" (most are 01 that have no sub-items at all) - only exception:
RETURN-CODEis recognized as "integer" ()
Compiling with/without -fdump-all doesn't change anything here. Any idea where to look at next? Is this an issue that only occurs in this environment?
Can you compare the variable tree printed in verbose mode with the Data Storage variables (all cob_u8_t) and Field variables (all cob_field) present in the *.c.l.h?
The variable tree panel built by the extension should be a perfect mirror of the variable tree printed in the terminal and the variables present in the files abovementioned (including cob_attributes).
Not sure what you're actually asking for here...
That is some of the output:
kf512_.b_2[null] > RETURN-CODE
kf512_.b_8[null] > XKC
...
kf512_.RETURN-CODE[null] > b_2
kf512_.XKC[null] > b_8
...
stdin: 17-stack-list-variables --thread 1 --frame 0 --simple-values
stdout: 17^done,variables=[{name="entry",arg="1",type="const int",value="0"},{name="initialized",type="unsigned int",value="1"},{name="module",type="cob_module *",value="0x131cdc0"},{name="cob_glob_ptr",type="cob_global *",value="0x1312fd8"},{name="h_GENXKC",type="cob_file *",value="0x131cf08"},{name="h_GENXKC_status",type="unsigned char [4]"},{name="call_SUBPROG1",type="cob_call_union"},{name="call_SUBPROG2",type="cob_call_union"},{name="call_SUBPROG3",type="cob_call_union"},{name="i1",type="int",value="6"},{name="f0",type="cob_field"},{name="cob_procedure_params",type="cob_field *[2]"},{name="frame_overflow",type="struct cob_frame *",value="0x98fd10"},{name="frame_ptr",type="struct cob_frame *",value="0x98f128"},{name="frame_stack",type="struct cob_frame [255]"},{name="b_2",type="int",value="0"},{name="b_8",type="unsigned char [200]"},...