What does not work with cbreak? Do you have a reproducer?
In the meanwhile just use break with source and line number SOME.cob:1234 - that should always work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, thats a version that doesn't understand the linespec. I can have a look tomorrow if I see it in my local version where the change for that is, so you can patch an also use linespec with cbreak.
Note: it does make sense to also create linespec breakpoints with cbreak, as only its breakpoints can be post-adjusted with ccondition later to break depending on an expression.
But in your case you'd do cbreak SALONSSAVY - which will break at the main ENTRY of the program (the first statement in the PROCEDURE DIVISION out of DECLARATIVES (that's what you already have) or cbreak section ini-processing - please see help cbreak.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tonight I continued working on this. I had built GC312 32 and 64 for MinGW last week. I installed CBL-GDB4.28. I was able to debug my application by using all the commands for CBL-GDB.
I decided to try using cobcd.py for version 4.28 on Linux. I was able to debug my application by using all the commands again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is anyone on this thread able to demo debugging in about twelve hours?
We are going to have a jitsi meeting about debugging. I suspect we will not have a speaker but I am still going to attempt to have the meeting as a practise run for jitsi.
Last edit: Simon Sobisch 2022-05-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What does not work with
cbreak? Do you have a reproducer?In the meanwhile just use
breakwith source and line numberSOME.cob:1234- that should always work.Simon,
CBreak does not really set the break point. When I use the
runcommand, it justs continues the program to conclusion.Yes, that is what I have done, when a CBL-GDB command does not work, I revert to the standard gdb command.
Then check with
info breakwhat was generated - if anything, maybe you already spot an issue.Attached are two screenshots; first is
cbreakthat does not work. The other is thebreakthat works.Ah, thats a version that doesn't understand the linespec. I can have a look tomorrow if I see it in my local version where the change for that is, so you can patch an also use linespec with
cbreak.Note: it does make sense to also create linespec breakpoints with cbreak, as only its breakpoints can be post-adjusted with
cconditionlater to break depending on an expression.But in your case you'd do
cbreak SALONSSAVY- which will break at the mainENTRYof the program (the first statement in thePROCEDURE DIVISIONout ofDECLARATIVES(that's what you already have) orcbreak section ini-processing- please seehelp cbreak.Tonight I continued working on this. I had built GC312 32 and 64 for MinGW last week. I installed
CBL-GDB4.28. I was able to debug my application by using all the commands forCBL-GDB.I decided to try using
cobcd.pyfor version 4.28 on Linux. I was able to debug my application by using all the commands again.I am hijacking this thread for one question...
Is anyone on this thread able to demo debugging in about twelve hours?
We are going to have a jitsi meeting about debugging. I suspect we will not have a speaker but I am still going to attempt to have the meeting as a practise run for jitsi.
Last edit: Simon Sobisch 2022-05-04
Unfortunately, I am not that speaker if you are looking to me. I am just getting my legs under me with debugging. Today is not good for me.
Rich Di Iulio
We have scheduled the next meeting:
https://www.meetup.com/worldwide-gnucobol-user-group/events/285696973/
Last edit: Simon Sobisch 2022-05-05