cbl-gdb-vsextension issueshttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues2021-12-28T16:56:24Zhttps://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).rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/19missing display on hover2021-05-08T12:04:16ZSimon Sobischmissing display on hoverCurrently this is explicit disabled at
[mibase.ts](CblGdbExt/CblGdb/src/mibase.ts#L640) with the note
> Hover is too hard for the moment. 2020-08-06 RJDUBNER
> Showing a variable on hover is much-requested, and I understand why. How...Currently this is explicit disabled at
[mibase.ts](CblGdbExt/CblGdb/src/mibase.ts#L640) with the note
> Hover is too hard for the moment. 2020-08-06 RJDUBNER
> Showing a variable on hover is much-requested, and I understand why. However, theVSC library routines that provide the expression to be evaluated interpret dash as a separator. So, hovering over "custmas-ctr" will show up here as "custmas" or "ctr". I haven't been able to figure out how to determine that the contiguous characters behind either of them are "custmas-ctr". So, we are out of luck on hovering.
I now took the time and check where this comes from and how this can be worked around:
vscode debug browser ui used to split words by the following:
```typescript
// Match any character except a set of characters which often break interesting sub-expressions
let expression: RegExp = /([^()\[\]{}<>\s+\-/%~#^;=|,`!]|\->)+/g;
```
But since vscode 1.43 there is a new [Debug hover API](https://code.visualstudio.com/updates/v1_43#_debugger-extension-api) to let language providers - or debugging extensions - have something to say about what is an actual word that is (likely to be) resolved as an expression.
For the extension I'd normally suggest to use I've also created [a PR](https://github.com/spgennard/vscode_cobol/pull/281) to provide the valid COBOL naming scheme to vscode.
In general I'd say: the current disabling here should be removed - just query the data (with a limit of 1!) of what is passed to `evaluateRequest` - if in your example only one match exists for "ctr" then the correct content will be shown - if there are multiple matches (are actually none) nothing is shown, but that's not up to this extension to handle other than to "not explode".
_Theoretically_ this extension could also handle this by implementing the `EvaluatableExpressionProvider` by using the known variables in the current file.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/18high-priority-bug: extension should use interpreter-exec instead of stdin/str...2021-03-26T06:43:10ZSimon Sobischhigh-priority-bug: extension should use interpreter-exec instead of stdin/stream writeAfter multiple cases of a "crashed" debugging session I gave bug hunting a try. And I'm quite sure that the `sendRaw` function is the reason for most bugs.
https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/blob/Version4.2.2/C...After multiple cases of a "crashed" debugging session I gave bug hunting a try. And I'm quite sure that the `sendRaw` function is the reason for most bugs.
https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/blob/Version4.2.2/CblGdbExt/CblGdb/src/backend/mi2/mi2.ts#L1048
The current implementation of for example `cprint` calls is to just send it to the GDB console.
This is problematic because:
* GDB will only execute the command if it waits for console input
* if the extension then waits for an answer the debugger halts and you need to restart the debugging session
* COBOL `ACCEPT` gets that data if the GDB console only waits on stdin input
* it needs a distinguishing between SSH or direct GDB
There's an MI command to do stuff like this: [The `-interpreter-exec` Command][2].
To allow the vsix to be useable: please use that and try to not use any stdin/stream functions.
[2]:https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Miscellaneous-Commands.html#The-_002dinterpreter_002dexec-CommandSimon SobischSimon Sobischhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/17handle watchpoint-trigger event2021-07-19T15:53:08ZSimon Sobischhandle watchpoint-trigger eventStart process, set watchpoint via debug console, continue (and have the variable be changed).
Result:
GDB stops at the line that is responsible for the change (as expected) but a red popup is shown in the editor window:
> Exception occ...Start process, set watchpoint via debug console, continue (and have the variable be changed).
Result:
GDB stops at the line that is responsible for the change (as expected) but a red popup is shown in the editor window:
> Exception occured
and the debug console has a note
> Not implemented stop reason (assuming exception): watchpoint-trigger
Please handle that gracefully ideally give a visual output of changed variable in the editor window).
While it is a "feature request" I'd consider that also a "bug" because `cwatch` is one of cobcd's functions.
No need to rush this because it is only a UI issue - it still "works" (in this case the new value is shown in the debug console).
[The bigger feature request is to handle watch via the watch window but that's a bigger thing which should be done later.]rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/16configure the range for the automated variable view in the extension and/or l...2021-03-26T06:40:25ZSimon Sobischconfigure the range for the automated variable view in the extension and/or launch configurationCurrently the automated variable view uses whatever is setup by `cprint /r` beforehand (which can also be done via environment variable `CPRINT_R`). The current workaround to adjust this is by specifying `cprint/r 999` (for disabling it)...Currently the automated variable view uses whatever is setup by `cprint /r` beforehand (which can also be done via environment variable `CPRINT_R`). The current workaround to adjust this is by specifying `cprint/r 999` (for disabling it) or any other value as needed in the launch configuration under `autorun`.
This should be adjusted to explicit request the range which needs adjustments in cobcd.py first (cbl-gdb#50).
Furthermore if the value is disabled then `cprint/m ?` should not be issued from the extension.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/15use cbreak instead of break2021-03-15T07:21:27ZSimon Sobischuse cbreak instead of breakSetting breakpoints via UI works in general (with the culprits tracked in #12), but expectedly fails on conditional breakpoints. Editing a breakpoint and post set the condition to `SOME-parm="1234"` leads to:
> No symbol "SOME" in curre...Setting breakpoints via UI works in general (with the culprits tracked in #12), but expectedly fails on conditional breakpoints. Editing a breakpoint and post set the condition to `SOME-parm="1234"` leads to:
> No symbol "SOME" in current context. (from break-condition 8 SOME-parm="1234")
To solve this I suggest to try replacing `break-condition` by `cbreak` and if that worked delete the original breakpoint (or, if that comes first in cobcd.py replace `break-condition` by `cbreak-condition`.
No high-priority bug because it can be worked around with doing the same as noted above in the debug console. Also I'd wait if "someone" may provide `cbreak-condition` :-)https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/14add support for configureable gdb path substitution2021-03-12T15:05:32ZSimon Sobischadd support for configureable gdb path substitutionAlso see https://github.com/WebFreak001/code-debug/pull/221/files.
After pulling in these changes it will be possible to have:
```json
"pathSubstitutions": {
"/root": "/home/username",
"/root2": "/home/username/common"
}
```
As...Also see https://github.com/WebFreak001/code-debug/pull/221/files.
After pulling in these changes it will be possible to have:
```json
"pathSubstitutions": {
"/root": "/home/username",
"/root2": "/home/username/common"
}
```
As a **workaround** one can add those to the autorun commands manually:
```json
"autorun": [
"set substitute-path /root /home/username",
"set substitute-path /root2 /home/username/common",
]
```rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/13Implement exceptions (stop in / after cob_runtime_error)2021-03-02T14:28:45ZSimon SobischImplement exceptions (stop in / after cob_runtime_error)When reporting https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/12#note_334 I was excited to see the way exceptions are handled (red box showing up containing the exception's description).
It would be nice to handle al...When reporting https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/12#note_334 I was excited to see the way exceptions are handled (red box showing up containing the exception's description).
It would be nice to handle all error messages that come from libcob (all running through `cob_runtime_error`) that way, effectively stopping the program before the normal `exit(1)` is called.
This has the benefit of being able to inspect the program's state in this case.
Ideally this would be handled in cobcd.py first (and the vsix-extension could then use that) - see https://gitlab.cobolworx.com/COBOLworx/cbl-gdb/-/issues/47 for tracking this.
Note: strangely the workaround I've applied and that works in plain GDB does not work in this extension.rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/12Not able to set/see breakpoints via the UI2021-03-15T06:17:43ZSimon SobischNot able to set/see breakpoints via the UIRemark: I'm currently only using "attach" so this may be only related to this.
Expectation:
* have [F9] toggle breakpoint ... toggle the breakpoint
* be able to click on a line to add to the breakpoints
* be able to manually enter a br...Remark: I'm currently only using "attach" so this may be only related to this.
Expectation:
* have [F9] toggle breakpoint ... toggle the breakpoint
* be able to click on a line to add to the breakpoints
* be able to manually enter a breakpoint in the breakpoint view of vscode and have the extension sending the appropriate breakpoint command to GDB
* ideally do this via th new `cbreak` implementation, which should also allow conditional breakpoints (at least for the current run)rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/11add launch attribute stopOnEntry (start instead of run / implicit break on at...2021-03-16T07:57:02ZSimon Sobischadd launch attribute stopOnEntry (start instead of run / implicit break on attach)The `stopOnEntry ` is noted in the [vscode debugging docs][1] as "break immediately when the program launches".
To support that change Adjust https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/blob/bobdev/CblGdbExt/CblGdb/src/...The `stopOnEntry ` is noted in the [vscode debugging docs][1] as "break immediately when the program launches".
To support that change Adjust https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/blob/bobdev/CblGdbExt/CblGdb/src/backend/mi2/mi2.ts#L625 to do `exec-run --start` https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Program-Execution.html#GDB_002fMI-Program-Execution and likely invoke `cstart` (as shipped in cobcd.py 4.2.2) then to actually stop at the first program's first statement.
Note: the COBOL devs I've spoken commonly want the program to start and hold at the first COBOL line, implementing this as noted above should provide a clean way to do so.
The implementation above should work fine with `Launch` configurations, for `Attach` an implicit `exec-stop` (to "break" wherever the program is), and then ideally switching to the most current COBOL frame would be the way to go.
[1]:https://code.visualstudio.com/docs/editor/debugginghttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/3add remote-debug options2021-03-12T11:57:22ZSimon Sobischadd remote-debug optionsto the launch configuration if it is necessary (maybe the normal attach works) and in any case to the README for how to setup the remote and how to attach using this extension
hint: I've provided notes concerning this via mail, you may ...to the launch configuration if it is necessary (maybe the normal attach works) and in any case to the README for how to setup the remote and how to attach using this extension
hint: I've provided notes concerning this via mail, you may use these after making them "anonymous"rdubnerrdubnerhttps://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/issues/1get the extension to the open vsx registry2020-09-04T06:27:40ZSimon Sobischget the extension to the open vsx registryhttps://open-vsx.org/?search=cobol still doesn't has an entry for this, but I think most is setup to publish a first alpha version (at least if it still work with smaller programs compiled and executed on the same machine).
Even the [na...https://open-vsx.org/?search=cobol still doesn't has an entry for this, but I think most is setup to publish a first alpha version (at least if it still work with smaller programs compiled and executed on the same machine).
Even the [namespace COBOLworx was claimed already](https://github.com/eclipse/open-vsx.org/issues/79)!rdubnerrdubner