Simon Sobisch

The configuration is fine - I've asked you to contribute similar code you've added to this extension (all `gdbtty` related ones) to another extension (that is for general GDB debugging).

It is possible and it does work if you use a MinGW built of GnuCOBOL. For this extension to work with a msvc built of GnuCOBOL we'd need support for...

If you need to debug GnuCOBOL modules that were created by a MSVC-configured cobc you may want to have a look at [GixIDE](https://github.com/mridoni/gix)

> I would love to use MinGW based Gnucobol but I'm building a Windows 32 Cobol application (I have to use some win32 apis) The program also uses a c...

This one should really be tracked separately so I've moved it here. Theoretically `cobc` could generate an array of cob_fields for this, pre-set with the actual field position, but an...

I suggest to have a look at the dump code that is generated with `-fdump-all` as it shows how `OCCURS` can be handled (resolving the amount of the appropriate `depending`...

As that's were the initial implementation of the "cob_field" variant came from; @brunopacheco1 can you please have a look at this? Always setting this environment variable before calling `cobc` will...

> COBOL archive files .car ??? > What about [...] unit-testing? Everything that concerns linting/mapping would be useful to be unit tested (and depending on the current code structure may...

I don't know much about the clang environment. You may or may not need additional flags to compile "GDB compatible". In any case: try with the gdb command line first...

> I was quite lazy to get the latest GC and relied on BREW for that. In this case I suggest you post fix these: `cobc --info` -> note down...