GCC debugger for OS/2 - what if...?

[Mentore]

While porting software to OS/2 I often get caught in long printf sessions to trace variables and such.
ISTR that debugging GCC binaries on OS/2 has become impossible due to reasons unknown to me.

I'm wondering if, maybe with the help of Codex, Claude or other AI assistant, would it be possible to have back some real time debugging / tracing under OS/2. I'm not asking for a full featured debugger on an IDE like Visual Studio (which, I have to admit, is really incredibly powerful, even a bit of an overkill), but not having to printf everything could be refreshing.

Can someone help me better understand the question?

Mentore

[Dariusz Piatkowski]

Hello Mentore!

...I'm wondering if, maybe with the help of Codex, Claude or other AI assistant, would it be possible to have back some real time debugging / tracing under OS/2. I'm not asking for a full featured debugger on an IDE like Visual Studio (which, I have to admit, is really incredibly powerful, even a bit of an overkill), but not having to printf everything could be refreshing...

Not an answer on it's own, but could the IBM C/C++ toolset be used for that purpose?

In other words: could a GCC compiled code be debugged with idedebug.exe that comes with IBM C/C++ 3.6.5?

EDIT
====
I suppose that's easy enough to test, a simple "Hello World" piece of code will do. What's the GCC 'enable debug' flag that I need to use?

[Martin Iturbide]

Hello Mentore

I don't complete understand your issue, but what I'm doing with AI is, putting the code in a shared drive between "Windows" (here I have the Claude AI cliente) and my ArcaOS VM development system. I even let the AI know I'm using a shared drive between the two systems.

I ask Claude to check the code, improve it, and at the end it tells me the command to run on ArcaOS to compile, this command has the required logs files. When the compile ends on ArcaOS, I go back to Windows with Claude and tell it that it's done and to start reading the logs.

The AI understand the problems and fix the issues as far as I had tested it.

I'm guessing that if you produce your logs fine in ArcaOS, you can ask the AI to help you trace the variables.

Regards

[Dave Yeo]

The IBM debuggers do mostly work with GCC compiled programs. There is a problem where the stack occasionally gets lost IIRC.
I note that KOMH recently posted some patches to get GDB working, at least in his Linux cross-compile environment. Untested here.
Dariusz, the debug flag for GCC is -g. You also need LDFLAGS=-Zomf or simply -Zomf. eg at the simplest,

Code: [Select]

gcc -g -Zomf hello_world.c


[KO Myung-Hun]

Hi/2.

I note that KOMH recently posted some patches to get GDB working, at least in his Linux cross-compile environment.

Nope. It's working on native OS/2 env both with old EMX binaries and kLIBC binaries.

KO Myung-Hun

[Dave Yeo]

Hi/2.

I note that KOMH recently posted some patches to get GDB working, at least in his Linux cross-compile environment.

Nope. It's working on native OS/2 env both with old EMX binaries and kLIBC binaries.

KO Myung-Hun

Good. Does the old EMX gdb work or do we need a new build?

[Dariusz Piatkowski]

The IBM debuggers do mostly work with GCC compiled programs. There is a problem where the stack occasionally gets lost IIRC.
I note that KOMH recently posted some patches to get GDB working, at least in his Linux cross-compile environment. Untested here.
Dariusz, the debug flag for GCC is -g. You also need LDFLAGS=-Zomf or simply -Zomf. eg at the simplest,

Code: [Select]

gcc -g -Zomf hello_world.c


OK, sounds good, I will give that a try.

I was thinking about the whole mix of:
-gdwarf
-gstabs
-gxcoff
-glevel
-ggdblevel
-gstabslevel
-gxcofflevel
-gvmslevel
etc...

I haven't used anything beyond that regular '-g' and wasn't sure if there was something more specific to enable our IBM C/C++ debugger to work.

[Dave Yeo]

I haven't used anything beyond that regular '-g' and wasn't sure if there was something more specific to enable our IBM C/C++ debugger to work.

Just the -Zomf to convert the binary into OMF format. Linking with -Zomf is good practice anyways as it uses the system linker.

[Mentore]

I haven't used anything beyond that regular '-g' and wasn't sure if there was something more specific to enable our IBM C/C++ debugger to work.

Just the -Zomf to convert the binary into OMF format. Linking with -Zomf is good practice anyways as it uses the system linker.

OK, so it seems I was simply doing some garbage in my mind! 8-)
Looks promising. I'll surely try that - now that I remember, I still have to reinstall VAC 3 and 3.65 with all the fixpacks. Let's see where this will bring me.

Mentore

[Dave Yeo]

OK, so it seems I was simply doing some garbage in my mind! 8-)
Looks promising. I'll surely try that - now that I remember, I still have to reinstall VAC 3 and 3.65 with all the fixpacks. Let's see where this will bring me.

Mentore

Actually, now we're using wlink or the RPM wl.exe (watcom-wlink-hll.rpm) for linking. Ilink does work but really you want 5.0 as it handles / well.
IIRC installing the RPM will modify config.sys so after a reboot it should work. Otherwise run emxomfld with no parameters to see the relevant environmental variables.

[KO Myung-Hun]

Hi/2.

I note that KOMH recently posted some patches to get GDB working, at least in his Linux cross-compile environment.

Nope. It's working on native OS/2 env both with old EMX binaries and kLIBC binaries.

KO Myung-Hun

Good. Does the old EMX gdb work or do we need a new build?

Already done: https://github.com/komh/gdb-os2/releases/tag/4.16-k1