x64 C (or C++) compiler & debugger for realtime applications

Programming, for all ages and all languages.
Post Reply
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

x64 C (or C++) compiler & debugger for realtime applications

Post by rdos »

So, are there any free C / C++ compilers for x64 (long mode) that have a lean libc that is not Posix compliant (and thus not enormous in size and effort to port to a new environment), which comes with a decent source-level debugger for Windows that can run over TCP/IP using a well-documented protocol? I don't need files or stdio, but having good math and possibly signal processing functions would be an advantage.
Octocontrabass
Member
Member
Posts: 5568
Joined: Mon Mar 25, 2013 7:01 pm

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by Octocontrabass »

GCC (or Clang) and GDB with your choice of frontend. On Windows, you might need run them with WSL, MSYS2, or Cygwin.

Compilers don't include a C library, that's separate. I'm not familiar with many different C libraries, but newlib looks like it has pretty good math functions. You might also want to check the list of C libraries here if you haven't already.
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by rdos »

Octocontrabass wrote:GCC (or Clang) and GDB with your choice of frontend. On Windows, you might need run them with WSL, MSYS2, or Cygwin.

Compilers don't include a C library, that's separate. I'm not familiar with many different C libraries, but newlib looks like it has pretty good math functions. You might also want to check the list of C libraries here if you haven't already.
I've looked at GDB before, but it requires autoconf, building crosscompilers and a lot of other stuff too. I obviously cannot build gdbserver on RDOS since I cannot handle autoconf, and RDOS target is not supported in the GNU toolchain. This is the hopelessly difficult path that I rather not go down. Also note that Windows is not supported, and so you must use Cygwin, which cannot run the debugger in graphics mode.

There has to be a better solution than this....
Octocontrabass
Member
Member
Posts: 5568
Joined: Mon Mar 25, 2013 7:01 pm

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by Octocontrabass »

rdos wrote:I've looked at GDB before, but it requires autoconf, building crosscompilers and a lot of other stuff too.
This isn't difficult in WSL. It can be a bit more of a challenge in MSYS2 or Cygwin, since you may need to use patched tools.
rdos wrote:I obviously cannot build gdbserver on RDOS since I cannot handle autoconf, and RDOS target is not supported in the GNU toolchain.
The GDB protocol is well-defined, so you can make your own gdbserver replacement. Or, you could port a GDB stub, but those are designed for kernel and embedded debugging, so you'd need to make some modifications if you want to use it in ring 3.
rdos wrote:Also note that Windows is not supported, and so you must use Cygwin, which cannot run the debugger in graphics mode.
The very first frontend on the list from earlier (gdbgui) is browser-based, so GDB itself can run in Cygwin while you use a native browser.
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by rdos »

Octocontrabass wrote:
rdos wrote:I've looked at GDB before, but it requires autoconf, building crosscompilers and a lot of other stuff too.
This isn't difficult in WSL. It can be a bit more of a challenge in MSYS2 or Cygwin, since you may need to use patched tools.
rdos wrote:I obviously cannot build gdbserver on RDOS since I cannot handle autoconf, and RDOS target is not supported in the GNU toolchain.
The GDB protocol is well-defined, so you can make your own gdbserver replacement. Or, you could port a GDB stub, but those are designed for kernel and embedded debugging, so you'd need to make some modifications if you want to use it in ring 3.
rdos wrote:Also note that Windows is not supported, and so you must use Cygwin, which cannot run the debugger in graphics mode.
The very first frontend on the list from earlier (gdbgui) is browser-based, so GDB itself can run in Cygwin while you use a native browser.
That's a bit interesting. So then the primary issue becomes if I can compile & build a binary that is OS independent and then debug it in an "embedded" target with gdbgui? I suppose newlib for an embedded system can fix that, but the GNU environment requires specific targets that are implemented in all the tools. Maybe there is an embedded target that fulfills that?
lmemsm
Posts: 18
Joined: Wed Jul 17, 2019 2:27 pm
Contact:

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by lmemsm »

rdos wrote:
Octocontrabass wrote:GCC (or Clang) and GDB with your choice of frontend. On Windows, you might need run them with WSL, MSYS2, or Cygwin.

Compilers don't include a C library, that's separate. I'm not familiar with many different C libraries, but newlib looks like it has pretty good math functions. You might also want to check the list of C libraries here if you haven't already.
I've looked at GDB before, but it requires autoconf, building crosscompilers and a lot of other stuff too. I obviously cannot build gdbserver on RDOS since I cannot handle autoconf, and RDOS target is not supported in the GNU toolchain. This is the hopelessly difficult path that I rather not go down. Also note that Windows is not supported, and so you must use Cygwin, which cannot run the debugger in graphics mode.

There has to be a better solution than this....

This may not be useful, but I've built gdb on Windows (native not Cygwin) and on DOS with djgpp (older version of gcc/gdb). I built gdb with pdcurses so that the Text User Interface is available for a GUI (on Windows or DOS). I also investigated the possibility of running gdb with fldev at one point. (FLTK can be built using nano-x which can port to a wide variety of platforms including DOS.) If a configure file is already generated, you usually don't need autoconf, just bash and whatever tools the configure file needs. I've run across some older versions of gcc/gdb that can be built with just a makefile. I've also used CDetect on some projects to replace autoconf. It's not a one for one replacement, but I can usually code something in a day or two that does the same thing configure would do for a project and then autoconf and automake are no longer needed.
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: x64 C (or C++) compiler & debugger for realtime applicat

Post by bzt »

rdos wrote:I obviously cannot build gdbserver on RDOS since I cannot handle autoconf, and RDOS target is not supported in the GNU toolchain. This is the hopelessly difficult path that I rather not go down.
Well, if it's enough to debug RDOS running in a VM, then there's an easy way out: qemu has a built-in gdbserver, ready to use, no modification needed on your part. Just add "-S -s" to the command line.

For debugging on real hardware, you can implement your own version of gdbserver. It's not that difficult, but definitely not a beginner level task. I think you can cope. This documentation will be useful: Writing a GDB Remote Serial Protocol server.
rdos wrote:Also note that Windows is not supported, and so you must use Cygwin, which cannot run the debugger in graphics mode.
There's a native Windows version wingdb, but it's not free. Why do you need graphics mode anyway? GDB TUI is pretty neat. But if you insist, you could give a try to gdbgui, which is written in Python, so there should be no problem running it under Windows. If everything else fails, I'm sure you can compile GDB with a GUI using MINGW which creates a native Windows app. You might need a Windows X11 server like Xming, but that's the worst case scenario.

(Note I haven't used these software, so I'm just suggesting to try them out. I don't want to imply any of them can fulfill your needs, just maybe. I've used Xming 10 years ago or so, there might be a better alternative. It was working great back then.)

Cheers,
bzt
Post Reply