I've previously posted a sample config, here's an updated one ("obviously" simplified, but still quite complete and "complex enough") which is saved as Project1.code-workspace with a directory layout of
src
src/sub1
src/sub2
scr <- different project specific scripts
conf <- multiple files including Project1.code-workspace
bin
Building is done via make (also could be done by a script) which does the actual compile and stores the output (stderr/stdout) in a file "per source", then ends with outputting them. This has the benefit that one can later just output (cat) those to get the project's full compilation result (including warnings/hints) within seconds to have them showing up in vscode's "problem pane" (recompilation of everything would take hours).
For "make"-people (otherwise ignore the remark): The comp_result and check- targets are .PHONY to ensure they are always executed.
As the GDB commands for setup (including source /path/to/cobcd.py and additional user-commands, "always on" breakpoints and others are a bigger list and those are a bit "dynamic" they are generated by a python script, if they are "quite fixed" they can of course be static (which removes the prelaunch task currently used).
Note: Currently the bitlang and cobolworx extensions must be installed manually (they are not available on open-vsx).
{"folders":[{"path":"../src","name":"src"},{"path":"../scr","name":"scripts"},{"path":"../conf","name":"configs"},],"extensions":{"recommendations":["bitlang.cobol","bitlang.gnucobol","usernamehw.errorlens","drmerfy.overtype","ms-vscode.hexeditor","cobolworx.cbl-gdb"],"unwantedRecommendations":["olegkunitsyn.gnucobol-debug",]},"settings":{//thefollowingsettingsareshownas"unknown"-weusethose//toreference'emvia${config:},allowingdifferentprojects//tobenearlyidentical"my.prj":"pr1","my.stage":"dev",//"my.userId":"001",//keptinuserconfig"debug.allowBreakpointsEverywhere":true,"files.autoGuessEncoding":true,"files.associations":{"*.i":"COBOL","*.dump":"COBOL_GNU_DUMPFILE","*.gdb":"shellscript",},"[COBOL]":{"files.encoding":"iso885915","files.autoGuessEncoding":false},"coboleditor.copybookexts":["cpy",],"coboleditor.program_extensions":["cbl","cob"],"coboleditor.copybookdirs":["sub1","sub2",],"coboleditor.fileformat":[{"pattern":"**/*.i","sourceformat":"free"},{"pattern":"**/*","sourceformat":"fixed"}],"coboleditor.sourceview":false,"coboleditor.enable_data_provider":true,"coboleditor.cache_metadata_user_directory":"../../pr1dev","coboleditor.cache_metadata":"user_defined_directory","coboleditor.process_metadata_cache_on_start":true,"coboleditor.cache_metadata_show_progress_messages":true,//"coboleditor.pre_parse_line_limit":250,"coboleditor.copybooks_nested":true,"coboleditor.parse_copybooks_for_references":false,"coboleditor.experimental_features":true,"coboleditor.fileformat_strategy":"always_fixed","coboleditor.intellisense_include_uppercase":true,"coboleditor.intellisense_include_unchanged":false,"coboleditor.format_on_return":"uppercase","coboleditor.linter":true,"coboleditor.linter_unused_paragraphs_or_sections":false,"editor.maxTokenizationLineLength":80000,"errorLens.gutterIconsEnabled":true,"errorLens.statusBarMessageEnabled":true,"errorLens.statusBarColorsEnabled":true,"errorLens.messageEnabled":true,"editor.tokenColorCustomizations":{"textMateRules":[{"scope":"keyword.operator.cobol","settings":{"foreground":"#0A90C2",}},{"scope":"comment.line.cobol.newpage","settings":{"foreground":"#ffff00","fontStyle":"italic bold underline",}}]},"overtype.labelInsertMode":"Ins","overtype.labelOvertypeMode":"Ovr",},"tasks":{"version":"2.0.0","inputs":[{"id":"prj","description":"Project","type":"pickString","options":[{"label":"Project 1 - Development","value":"pr1dev"},{"label":"Project 1 - Testing","value":"pr1t"},{"label":"Project 1 - Release","value":"pr1r"},{"label":"Project 2 - Development","value":"pr2dev"},{"label":"Project 2 - Testing","value":"pr2t"},{"label":"Project 2 - Release","value":"pr2r"},{"label":"Master for common components","value":"master"},],"default":"master"},{"id":"exeProgram","description":"Program to run","type":"promptString",},{"id":"pid","description":"pid to attach to","type":"promptString",},],"tasks":[{"label":"Build","command":"make","args":["-C","../bin","-f","${workspaceFolder:scripts}/Makefile","SRCDIR=${workspaceFolder:src}","all"],"presentation":{"echo":false,"reveal":"always","focus":false,"panel":"shared","clear":true},"problemMatcher":["$gnucobol3-error-cobc","$gnucobol3-warning-cobc","$gnucobol3-note-cobc","$gnucobol3-cobc",],"group":{"kind":"build","isDefault":true}},{"label":"Last compile result","command":"make","args":["-C","../bin","-f","${workspaceFolder:scripts}/Makefile","SRCDIR=${workspaceFolder:src}","comp_result"],"presentation":{"echo":false,"reveal":"always","focus":false,"panel":"shared","clear":true},"problemMatcher":["$gnucobol3-error-cobc","$gnucobol3-warning-cobc","$gnucobol3-note-cobc","$gnucobol3-cobc",],"group":"build"},{"label":"Check file","command":"make","args":["-C","../bin","-f","${workspaceFolder:scripts}/Makefile","SRCDIR=${workspaceFolder:src}","check-${fileBasenameNoExtension}"],"presentation":{"echo":false,"reveal":"always","focus":false,"panel":"shared","clear":true},"problemMatcher":["$gnucobol3-error-cobc","$gnucobol3-warning-cobc","$gnucobol3-note-cobc","$gnucobol3-cobc",],"group":"build"},{"label":"Build file","command":"make","args":["-C","../bin","-f","${workspaceFolder:scripts}/Makefile","SRCDIR=${workspaceFolder:src}","${fileBasenameNoExtension}.${config:my.objExt}"//objExt:setupintheusersetting],"presentation":{"echo":false,"reveal":"always","focus":false,"panel":"shared","clear":true},"problemMatcher":["$gnucobol3-error-cobc","$gnucobol3-warning-cobc","$gnucobol3-note-cobc","$gnucobol3-cobc",],"group":"build"},{"label":"Diff with other project","linux":{"command":"codium",},"windows":{"command":"VSCodium.exe",},"args":["--diff","${file}","../../${input:prj}/${relativeFile}"],"isBackground":true,"group":"none","problemMatcher":[]},{"label":"Show running COBOL","linux":{//scriptdoingsomethingalong"ps -fu `whoami` | grep 'cobcrun ' | grep -v 'grep\\|vim'""command":"${workspaceFolder:scripts}/running_cob.sh",},"windows":{"command":"${workspaceFolder:scripts}/running_cob.ps",},"args":["--prj=${config:my.prj}","--stage=${config:my.stage}",],"group":"none","problemMatcher":[],"presentation":{"echo":false,"reveal":"always","focus":true,"panel":"dedicated","showReuseMessage":false,"clear":false}},{"label":"execute program","command":"cobcrun","args":["${input:exeProgram}","${config:my.prj}",],"isBackground":true,"group":"none","problemMatcher":[]},{"label":"create GDB-CMD new","command":"${config:python.pythonPath}","args":["${workspaceFolder:scripts}\\GDB_CMD.py","--prj=${config:my.prj}","--stage=${config:my.stage}","--pid=","--output_file=../../tmp/${config:my.prj}${config:my.stage}${config:my.userId}.gdb"],"group":"none","problemMatcher":[],"presentation":{"echo":false,"reveal":"silent","focus":false,"panel":"shared","showReuseMessage":false,"clear":false}},{"label":"create GDB-CMD attach","command":"${config:python.pythonPath}","args":["${workspaceFolder:scripts}\\GDB_CMD.py","--prj=${config:my.prj}","--stage=${config:my.stage}","--pid=${input:pid}","--output_file=../../tmp/${config:my.prj}${config:my.stage}${config:my.userId}.gdb"],"group":"none","problemMatcher":[],"presentation":{"echo":false,"reveal":"silent","focus":false,"panel":"shared","showReuseMessage":false,"clear":false}}]},"launch":{"version":"0.2.0","inputs":[{"id":"prog","description":"program","type":"promptString","default":"PROGMAIN"},{"id":"args","description":"arguments for main program","type":"promptString","default":""},//note:pidispartoftheprelaunchTask],"configurations":[{"name":"new COBOL","type":"cbl-gdb","request":"launch","program":"cobcrun","arguments":"-M ../bin ${input:prog} ${input:args}","cwd":"${workspaceFolder:src}","preLaunchTask":"create GDB-CMD new","windows":{"gdbpath":"gdb-multiarch.exe",},"autorun":["source ../../../tmp/${config:my.prj}${config:my.stage}${config:my.userId}.gdb","cp/r -2",//disableautomaticcontext-view(performanceissue)],},{"name":"attach","type":"cbl-gdb","request":"attach","cwd":"${workspaceFolder:src}","preLaunchTask":"create GDB-CMD attach","windows":{"gdbpath":"gdb-multiarch.exe",},"autorun":["source ../../../tmp/${config:my.prj}${config:my.stage}${config:my.userId}.gdb","cp/r -2",//disableautomaticcontext-view(performanceissue)],//"showDevDebugOutput":true,},]}}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to wrap it like I do in my json files, but could not. I did notice you do not have this setting in your Settings section. If I did not have this, I could just have one workspace file.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bitlang.cobol does not inspect the complete workspace, but only named folders, you can either give an absolute position or just a name of a folder - this is what I do:
../conf <- project workspace
../src <- source
../src /sub1 <- more source, including copybooks
It is enough to specify "sub1" to have it parsed for COPY statements. It searches for this folder name in every folder in the workspace, you see this after start when opening the output pane, switching there to COBOL. You'll see " Combined Workspace and CopyBook Folders to search:" with a lot of entries (if you have lots of folders like this workspace has) and then even more "Invalid CopyBook directories" (in my case 36).
And you can specify as many invalid entries as you want...
I'd would go with (guessing that R:\salonsavvy is the place where your code-workpace file and sources reside
With some work and suggestions from Simon (many thanks), I have a single workspace file. Under Linux, I can build and debug my application. However, under Windows I cannot debug. It sounds like it cannot find gdb. I tried using gdbpath, but it did not help. Here is the error:
Could not start debugger process, does the program exist in filesystem?
Error: spawn gdb ENOENT
I even tried using gdb-muliarch.exe, still no joy! I thought the command spawn maybe want is missing. I could not seem to find that executable.
Now, should I just reside myself to not debug programs in Windows?
As always, thanks for any help.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this means it cannot find gdb. And yes, if you add/change the gdbpath setting in the launch configuration (to a path where a recent gdb.exe or gdb-multiarch.exe [mind the missing T in your post] resides) should work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Today I updated my Linux laptop, which updated VS Codium. Now the workspace configuration will not allow 'Linux" or "Windows". I tried to look for a workaround, but have not found one yet. I may have to go back to two versions of the workspace file.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you sure? I think this is possibly just related to the workspace trust and as soon as you enable that everything may work again. To check this: click on the "restricted" icon in the lower left, then choose "trust".
Okay, I found the change does not affect Tasks process. The errors appear in the Launch process. I ran a debug session just fine. Thank you for your response.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As already posted on SO - your question misses the - in this case quite important - information about the used versions:
of Oracle Linux
cbl-gdb package from COBOLworx
of the compiler - both GnuCOBOL and underlying C compiler - get by cobc -vV
Additional: Is cbl-gdb installed from source or from an RPM from their website?
Note that (cbl-gdb only supports version 3.1.2 or 3.2, the RPMs possibly only support 3.1.2 so far.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this case I'd suggest to update to 4.28.6, build again, then go to the tests3.1 directory and run make test.
If this fails similar then check with @rdubner-s or his team via support@cobolworx.com.
If it doesn't fail then install that and check again, if then still get your errors with your programs check with Bob, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good night Simon! I updated the version but it didn't work: [duma@cristal tests3.1]$ make test
make -C test001 test
make[1]: Entering directory '/home/duma/debug/cbl-gdb/tests3.1/test001'
COBCDEVEL=1 COBCDFMODE=0 /usr/bin/python3 ../../cobcd -x test.cbl
test.s: Assembler messages:
test.s:11324: Error: leb128 operand is an undefined symbol: .LVU824
test.s:11325: Error: leb128 operand is an undefined symbol: .LVU824
Thank you anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added these lines to cobcd and managed to compile my program:
## We need to get rid of '-Wp,-D_FORTIFY_SOURCE=2' That value completely
## messes up COBOL executables.
COB_CFLAGS_BASE = ' '.join(COB_CFLAGS_BASE)
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-Wp,-D_FORTIFY_SOURCE=2","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-Wp,-D_GLIBCXX_ASSERTIONS","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-D_FORTIFY_SOURCE=2","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-U_FORTIFY_SOURCE","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-O","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.split()
Sorry for my bad English.
Thanks,
Marcos M. Duma
Last edit: Marcos Martins Duma 2023-06-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trying to follow your suggestion (on another forum), I managed to get this script that I'm using on Linux:
/debug/external_debug.py
importosfrompathlibimportPathimportsubprocess,signalimporttimeimportplatformimportgdbdefread_num_terminal():home=Path.home()fileName=os.path.join(home,".numterm")ifnotos.path.isfile(fileName):returnNonefile1=open(fileName,"r")termName=file1.readlines()[0].strip()file1.close()returntermNamedefisTermOn():bTermIsOn=FalsetermName=read_num_terminal()#file exists?iftermName:searchStr=termName.split("/")[2]+"/"+termName.split("/")[3]ps=subprocess.Popen(('ps','-e'),stdout=subprocess.PIPE)output=ps.communicate()[0]forlineinoutput.decode("utf8").split('\n'):#print(line)ifline.find(searchStr)>=0andline.find("sleep")>=0:bTermIsOn=TruereturnbTermIsOndefmain():command1=Noneifplatform.system()=="Linux":# Open the new terminal - xtermifnotisTermOn():process=subprocess.Popen(["xterm","-title","GnuCobol Debug","-fa","DejaVu Sans Mono","-fs","16","-e","/usr/bin/tty>~/.numterm; sleep 1000000;"],stdin=subprocess.DEVNULL,stdout=subprocess.PIPE,stderr=subprocess.PIPE,start_new_session=True,preexec_fn=(lambda:signal.signal(signal.SIGHUP,signal.SIG_IGN)))# Read the tty device nametime.sleep(1)# Redirect to terminaltermName=read_num_terminal()command1='set inferior-tty '+termName# Using readlines()else:command1='set new-console'print(command1)gdb.execute(command1)if__name__=="__main__":main()
In the launch.json configuration clb-gdb I do the following:
I've previously posted a sample config, here's an updated one ("obviously" simplified, but still quite complete and "complex enough") which is saved as Project1.code-workspace with a directory layout of
Building is done via make (also could be done by a script) which does the actual compile and stores the output (stderr/stdout) in a file "per source", then ends with outputting them. This has the benefit that one can later just output (
cat) those to get the project's full compilation result (including warnings/hints) within seconds to have them showing up in vscode's "problem pane" (recompilation of everything would take hours).For "make"-people (otherwise ignore the remark): The
comp_resultandcheck-targets are.PHONYto ensure they are always executed.As the GDB commands for setup (including
source /path/to/cobcd.pyand additional user-commands, "always on" breakpoints and others are a bigger list and those are a bit "dynamic" they are generated by a python script, if they are "quite fixed" they can of course be static (which removes the prelaunch task currently used).Note: Currently the bitlang and cobolworx extensions must be installed manually (they are not available on open-vsx).
Simon,
The only thing in my workspace that is OS specific is the following:
"coboleditor.copybookdirs": [ "R:\\salonsavvy\\rjd", "R:\\salonsavvy\\lib", "R:\\common\\lib", "C:\\gc\\gc312\\share\\gnucobol\\copy" ],I tried to wrap it like I do in my json files, but could not. I did notice you do not have this setting in your Settings section. If I did not have this, I could just have one workspace file.
Rich Di Iulio
Simon,
I re-read your example and found that you do use
coboleditor.copybookdirs. However, what doessub1andsub2mean?Thank you for posting your workspace file. It has a lot of great ideas in it.
Rich Di Iulio
bitlang.cobol does not inspect the complete workspace, but only named folders, you can either give an absolute position or just a name of a folder - this is what I do:
../conf <- project workspace
../src <- source
../src /sub1 <- more source, including copybooks
It is enough to specify "sub1" to have it parsed for
COPYstatements. It searches for this folder name in every folder in the workspace, you see this after start when opening the output pane, switching there to COBOL. You'll see " Combined Workspace and CopyBook Folders to search:" with a lot of entries (if you have lots of folders like this workspace has) and then even more "Invalid CopyBook directories" (in my case 36).And you can specify as many invalid entries as you want...
I'd would go with (guessing that R:\salonsavvy is the place where your code-workpace file and sources reside
With some work and suggestions from Simon (many thanks), I have a single workspace file. Under Linux, I can build and debug my application. However, under Windows I cannot debug. It sounds like it cannot find gdb. I tried using
gdbpath, but it did not help. Here is the error:I even tried using
gdb-muliarch.exe, still no joy! I thought the command spawn maybe want is missing. I could not seem to find that executable.Now, should I just reside myself to not debug programs in Windows?
As always, thanks for any help.
Rich Di Iulio
Yes, this means it cannot find gdb. And yes, if you add/change the gdbpath setting in the launch configuration (to a path where a recent gdb.exe or gdb-multiarch.exe [mind the missing T in your post] resides) should work.
Today I updated my Linux laptop, which updated VS Codium. Now the workspace configuration will not allow 'Linux" or "Windows". I tried to look for a workaround, but have not found one yet. I may have to go back to two versions of the workspace file.
Rich Di Iulio
Are you sure? I think this is possibly just related to the workspace trust and as soon as you enable that everything may work again. To check this: click on the "restricted" icon in the lower left, then choose "trust".
Edit: for details and a way to fix that by @rdubner-s see https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension/-/merge_requests/7
Last edit: Simon Sobisch 2021-06-14
Simon,
Okay, I found the change does not affect
Tasksprocess. The errors appear in theLaunchprocess. I ran a debug session just fine. Thank you for your response.Rich Di Iulio
Hi!
I'm trying to use cobcd (cobolworkx) to debug a program. The command is returning the following error on Oracle Linux:
cobcd -x program.cob
program.s: Assembler messages:
program.s:13870: Error: leb128 operand is an undefined symbol: .LVU139
program.s:13871: Error: leb128 operand is an undefined symbol: .LVU139
As already posted on SO - your question misses the - in this case quite important - information about the used versions:
cobc -vVAdditional: Is cbl-gdb installed from source or from an RPM from their website?
Note that (cbl-gdb only supports version 3.1.2 or 3.2, the RPMs possibly only support 3.1.2 so far.
Cobolworkx: Version 4.28.4. Source: https://gitlab.cobolworx.com/COBOLworx/cbl-gdb
Linux: Oracle Linux Server release 8.7
Cobol: GnuCOBOL 3.1.2
Compiler: gcc 8.5.0
In this case I'd suggest to update to 4.28.6, build again, then go to the tests3.1 directory and run
make test.If this fails similar then check with @rdubner-s or his team via support@cobolworx.com.
If it doesn't fail then install that and check again, if then still get your errors with your programs check with Bob, too.
Good night Simon! I updated the version but it didn't work:
[duma@cristal tests3.1]$ make test
make -C test001 test
make[1]: Entering directory '/home/duma/debug/cbl-gdb/tests3.1/test001'
COBCDEVEL=1 COBCDFMODE=0 /usr/bin/python3 ../../cobcd -x test.cbl
test.s: Assembler messages:
test.s:11324: Error: leb128 operand is an undefined symbol: .LVU824
test.s:11325: Error: leb128 operand is an undefined symbol: .LVU824
Thank you anyway.
please keep us posted about the results you get with COBOLworx on this issue
Good night Simon!
In my case, Oracle Linux GCC is generating the "FORTIFY_SORCE" directive in a way not foreseen in cobcd:
gcc -pipe -Wall -Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs= /usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fstack-clash-protection -fcf-protection -fstack-protector-strong -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -I/usr/include -Wno-unused -fsigned-char -Wno-pointer-sign -O -fcf-protection=none -ggdb -o test.s test.c -S
/home/duma/debug/cbl-gdb/cobcd-sfix/cobcd-sfix -q test.s test.s test.c test.cbl
I added these lines to cobcd and managed to compile my program:
## We need to get rid of '-Wp,-D_FORTIFY_SOURCE=2' That value completely
## messes up COBOL executables.
COB_CFLAGS_BASE = ' '.join(COB_CFLAGS_BASE)
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-Wp,-D_FORTIFY_SOURCE=2","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-Wp,-D_GLIBCXX_ASSERTIONS","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-D_FORTIFY_SOURCE=2","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-U_FORTIFY_SOURCE","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.replace("-O","")
COB_CFLAGS_BASE = COB_CFLAGS_BASE.split()
Sorry for my bad English.
Thanks,
Marcos M. Duma
Last edit: Marcos Martins Duma 2023-06-09
Hi Simon!
Trying to follow your suggestion (on another forum), I managed to get this script that I'm using on Linux:
/debug/external_debug.py
In the launch.json configuration clb-gdb I do the following:
To run it, you need to call codium from the terminal, like this:
and then "F5" to start the debug.
I took the liberty of posting it because it might make it a little easier to start debugging.
Last edit: Marcos Martins Duma 2023-06-16