#3 attaching to a running process

[brunopacheco1]

This feature is not fully supported.

It attaches to a local running process, but due to the nature of this execution, the displaying variable values is not working properly, as it relies on a function (cob_display) to print a custom MI event and it is done on the running process terminal, not on the GDB terminal.

Even though #3 is not fully implement, as we could check remote debugging (different machines) and double-check different OS, I believe we should tackle the side-effect described before on a different issue.

[GitMensch]

@OlegKunitsyn I still would like to see this merged sooner than later (it is still an additional option and still marked as experimental work in progress). As long as everything compiles and the "common stuff" works I see the big benefit of a common code-base without merges back and forth.
@brunopacheco1 Could you split the general output #26 and by this also solve the issue of where the custom event is pushed to (or are those completely unrelated)?

[brunopacheco1]

I was playing around some solutions to redirect the outputs (GDB and running process) but no success so far.

Anyway, I would say to make everything working as the code is today the solution is to merge both outputs to the same file.

To have different files(or terminals/panels) for different outputs, first we would have to replace the away we do cob_field evaluation (either printing it to another file explicitly or getting the value in a different way).

[GitMensch]

To have different files(or terminals/panels) for different outputs, first we would have to replace the way we do cob_field evaluation (either printing it to another file explicitly or getting the value in a different way).

Do we need a "real" file or would a file stream passed to the evaluation be enough? A real file would likely be too much io, given the hundreds/thousands of fields "common" COBOL programs have.

Do you have an idea on how to get the value another way?

[OlegKunitsyn]

Just sketched up the structure of attach/detach supported by vscode. Please use attach branch.

[GitMensch]

@brunopacheco1 Any clue when you find the time to redo the changes based on what we currently have in the attach branch?