split the "view" (which runs) from the "compile"

[GitMensch]

if you find the need to do some pre-processing directly then have a cobcgdb wrapper (that would do cobc -g with every switch you find necessary - but a user may execute the same commands manually) and a cobgdb which is only the frontend

This has the benefit of allowing a connection to a running process/server later - and most important: people can compile now and debug 6 days later (or a real world application consisting of 500+ COBOL modules) without any problem. This is the biggest regression in gnucobol-debug which effectively prevents its use for those type of applications. Please don't copy that regression here.

[marcsosduma]

Understood, Simon. I'm fixing the code and making some adjustments. However, I'll try to perform this task, meaning considering that the program has already been compiled. My question is how to ensure that it was compiled in the way cobgdb needs it.

[GitMensch]

Don't ensure at all. GDB will give you different output / not find breakpoints if compiled "wrong".

Just provide a script (I suggest cobcg) to invoke the compiler as expected and let the user know that this is the preferred way to compile to be cobgdb ready.

[GitMensch]

Just checking: there still is a combined "compile and run", right?

Please adjust this to have it split - if you want to be backward compatible you can include a cobgdb.cmd (and script cobgdb script) which executes both parts.

Note that this also comes with the benefit of not needing to hard-wire that much information. -g -fsource-location is needed, so that could be auto-included in the new "compile" part, I hope that -ftraceall is not needed (at least not with GC 3.1+); -x should definitely only be included (in the wrapper script, -O0 may not be needed.

[marcsosduma]

Olá Simon! I ainda haven't altered this mechanism. I'm still trying to understand how to make this separation between compilation and debugging. Maybe reading the executable and loading the source code from the "info sources" command.

[GitMensch]

Maybe reading the executable and loading the source code from the "info sources" command.

Yes, that sounds good (note there are likely mi commands you can get this information from, too, in which case you don't need to parse the output of the user commands). Doing so would also allow to keep the C sources in a separate folder (for example "dbg") and instruct GDB to use this source directory - info source shows you where it is read from (no need to duplicate all that effort).

[GitMensch]

Do you need help with something specific here? As noted that's really the "big bummer" in the upstream issue (it just isn't usable with thousands of called modules) and therefore also here.

[marcsosduma]

Hi Simon! Any help is welcome. What can we do?

[GitMensch]

The very first thing is really to split compile from running as suggested here. I think it would ve clear to you how that would look like, no?

[marcsosduma]

Hi! I included the 'cobgdb --exe program' option to enable debugging of a previously generated executable with debug options. What do you think?