In Windows I have set the environment variable
set COBCPY=d:/bsp2/cpy;d:/bspgui41/cpy;
and have a COPY file CY020D with Cobol lines in my Procedure Division.
When compiled in the c source are generated lines as
How do you run the debugging? Plain cobc+gdb will only show the C view of the variables, to be useful from the COBOL view you'd need something to wrap those (the first were pre-processors like TP Debugger or WinAnim, then came live wrappers like gnucobol-debug then GDB plugins like cobcd and very COBOL specific ones like the ones shipped with GixIDE).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-10-05
Windows
cobc is version 3.1.2.0
compiled with cobcd
Debugger is Visual Studio Code with the Extension cbl-gdb-4.2.3.vsix
If I copy all my Procedure Division COPYs in my Project directory and recompile than I am able to view the variables.
If the COPYs are in a directory COB_COPY_DIR I cannot view variables and call stack.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe. I have test code that uses COPY to bring in variables and code, and it's working properly, last I checked, on both Windows and Linux.
It concerns me that COBC, in the reported scenario, is generating .C code that is subsequently confusing the following C compilation. I always get confused when there are escaped backslashes, but it seems to me that the filename in the generated line:
#line 9 "d:/bspgui41/cpy\\CY020D.CBL"
is somehow being interpreted as
d:/bspgui41/cpy\CY020D.CBL
which leads to the error message. And that would suggest that the original generated line needs to be
#line 9 "d:/bspgui41/cpy\\\\CY020D.CBL"
Although frankly, whether Windows or not, I wonder if things would work better if COBC stuck in a "/" instead of trying to sort out backslashes when creating #line directives.
But that's not really here nor there. If the generated .C code is generating errors when compiled by the follow-up C compiler, I am reluctant to debug what's happening after that; the original problem needs to be eliminated.
I am scanning and changing the .C file as part of the COBCD-ST process, and I could notice the original backslash problem and force in a fix. But that seems backwards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
In Windows I have set the environment variable
set COBCPY=d:/bsp2/cpy;d:/bspgui41/cpy;
and have a COPY file CY020D with Cobol lines in my Procedure Division.
When compiled in the c source are generated lines as
The c compiler produces warnings as
a968a.c:18191:1: warning: unknown escape sequence: '\C'
If I debug the program I am able to step into the code in the copy file but no variables can be examined.
I assume the problem is the backslash generated at the end of the copy directory.
Is there any setting to replace the backslash with a slash?
Kind regards
Frank
mod edit for source code markdown
Last edit: Brian Tiffin 2021-10-04
What does
say?
How do you run the debugging? Plain cobc+gdb will only show the C view of the variables, to be useful from the COBOL view you'd need something to wrap those (the first were pre-processors like TP Debugger or WinAnim, then came live wrappers like gnucobol-debug then GDB plugins like cobcd and very COBOL specific ones like the ones shipped with GixIDE).
Windows
cobc is version 3.1.2.0
compiled with cobcd
Debugger is Visual Studio Code with the Extension cbl-gdb-4.2.3.vsix
If I copy all my Procedure Division COPYs in my Project directory and recompile than I am able to view the variables.
If the COPYs are in a directory COB_COPY_DIR I cannot view variables and call stack.
Maybe. I have test code that uses COPY to bring in variables and code, and it's working properly, last I checked, on both Windows and Linux.
It concerns me that COBC, in the reported scenario, is generating .C code that is subsequently confusing the following C compilation. I always get confused when there are escaped backslashes, but it seems to me that the filename in the generated line:
#line 9 "d:/bspgui41/cpy\\CY020D.CBL"is somehow being interpreted as
d:/bspgui41/cpy\CY020D.CBLwhich leads to the error message. And that would suggest that the original generated line needs to be
#line 9 "d:/bspgui41/cpy\\\\CY020D.CBL"Although frankly, whether Windows or not, I wonder if things would work better if COBC stuck in a "/" instead of trying to sort out backslashes when creating #line directives.
But that's not really here nor there. If the generated .C code is generating errors when compiled by the follow-up C compiler, I am reluctant to debug what's happening after that; the original problem needs to be eliminated.
I am scanning and changing the .C file as part of the COBCD-ST process, and I could notice the original backslash problem and force in a fix. But that seems backwards.