Debugging while using GCC

[JustinPayne]

Hey all,

I've already asked this over at the Atari Age forums but no bites so I thought I would post it here as well since it's more 16-bittie.

I've been beefing up my stale C knowledge by reading through C-manship, typing out the apps, and messing around on my own. I have PureC but I kinda like using GCC and Vincent Rivière's m68k-atari-mint cross-tools within STeem. So far, there have been a few conversion obstacles but with a little determination and help from another, I've been able to figure out most issues. Of course, my debugging at this point has been printf's and outputting to a log file. This isn't ideal so I loaded up Hisoft's Mon v3.10 but the docs aren't exactly helpful. I can't even figure out how to load up my app. It asks for a filename but for some reason I can't type a colon. When I hit Shift-:, it only gives semicolon. There also seems to be a few other keys that aren't responding. Since I'm compiling this in GCC and not using Lattice C, I'm not even sure this will work.
In any case, here is the question...
For those writing ST/TT/Falcon apps using GCC or G++, how are you performing your debugging? When I say, "How", I mean, in detail, what tools are you using, what environment are you doing this in, how would I set myself up to do it the same way, etc?

Thanks,
Michael

[mfro]

For those writing ST/TT/Falcon apps using GCC or G++, how are you performing your debugging? When I say, "How", I mean, in detail, what tools are you using, what environment are you doing this in, how would I set myself up to do it the same way, etc?

First things first: gcc works best with gdb.

Unfortunately the only version available for Atari/MiNT is pretty outdated since nobody took the challenge to port a later one. I'm not even sure if it will run on all hardware available (I think I remember having problems last time I tried).

You can however force gcc (more specifically, the linker) to produce debugging symbols understood by other ("Standard-Atari") debuggers.
Specify -g -Wl,--traditional-format for CFLAGS and you'll get "native-format symbolic debugging" binaries.

Do not expect too much, however. The DRI format basically supports symbols for labels (global variables and function names), not more.

[jfl]

For those writing ST/TT/Falcon apps using GCC or G++, how are you performing your debugging? When I say, "How", I mean, in detail, what tools are you using, what environment are you doing this in, how would I set myself up to do it the same way, etc?

I use GCC on my FireBee (no cross compiling for me) and did try GDB a while ago but soon found it was more trouble than it's worth. With the maximum set of warnings GCC catches a lot of my mistakes and as for the rest, well, I try not to introduce bugs But when I do, printf() is still my favourite method. It forces me to understand what I'm actually doing.

I also used Lint for a while, and it did catch some suspicious stuff in my code, but again I found that my time was better spent trying to learn to program properly. I suppose I'm kinda old school...

[wongck]

I use gcc on my Atari Falcon CT63 and trying to setup my FireBee to do this as well.
I am using the traditional method of printf only for debugging. At least on MINT it outputs to the console.

I tried using gdb couple of times. Breakpoints and peeking into the data, changing data, stepping each line.
It's do-able, but after being got used to Pure debugger of Pure C, I cannot get use to making command lines command of gdb.
So I very seldom use gdb.

For my current project (I hope to release soon for 2014), I used only the printf statements.
Sure it is a hassle to type a complete printf statement to see the data but it works.

[jfl]

For my current project (I hope to release soon for 2014), I used only the printf statements.
Sure it is a hassle to type a complete printf statement to see the data but it works.

Doesn't your editor handle macros? That's what I do with QED. I have a printf() statement binded to a function key. A form_alert() string to another key, etc. Makes life much easier. You just need to type the value you want to print.

[wongck]

Doesn't your editor handle macros? That's what I do with QED. I have a printf() statement binded to a function key. A form_alert() string to another key, etc. Makes life much easier. You just need to type the value you want to print.

What I mean was that you need to make the format string ( e.g.like "[%s] [%x]\r\n" ) to print the correct formatting/data format and then the variables name.
What I normally do is leave them in the source code and just // comment them out.
If I need one I just go copy from the commented out printf statment and then change the variable name.

This is not as fast as using the Pure Debugger.

I tried using the gdb over the network to a proper debugger in my windoze.... but that was too much of a hassle running 2 systems (not to mention lack of desk space for me).

[JustinPayne]

Thanks everyone for your response. I'm always surprised when I start doing something I think is "hacky" only to find out other devs are doing that same thing. I guess I should have more faith in my process.
As far as debugging, printf() would probably work but I use Eclipse a lot for Java and stepping code is a common occurence, one that is hard to break. Even when I did Assembly Language back in '92 I used breakpoint to step through the code. Printing debug always reminds me of debugging scripts.
Maybe I should really be doing this on my Falcon. I currently only have 4 gigs so I don't think Mint is an option at this time and to really develop comfortable, a true multitasking environment is needed.
Well, I think I have been presented with some good options. Now, which one to choose.

[jfl]

As far as debugging, printf() would probably work but I use Eclipse a lot for Java and stepping code is a common occurence, one that is hard to break. Even when I did Assembly Language back in '92 I used breakpoint to step through the code. Printing debug always reminds me of debugging scripts.

DDD is a good option for a graphical debugger for GCC, but you will need to run it remotely since it's never been ported to the Atari.

[wongck]

LOL... if you have 4 Gigs... that's definately more than enough for Mint.
I have less than that on my Falcon/CT63 system.
You mean 4MB I guess.

As far as debugging, printf() would probably work but I use Eclipse a lot for Java and stepping code is a common occurence, one that is hard to break. Even when I did Assembly Language back in '92 I used breakpoint to step through the code. Printing debug always reminds me of debugging scripts

Ah yes, Eclipse was one of those IDE that I was going to use for debugging applications on the Falcon.
Just set that up as the gdb client and you should be able to do it.

[dml]

I use GCC on my FireBee (no cross compiling for me) and did try GDB a while ago but soon found it was more trouble than it's worth. With the maximum set of warnings GCC catches a lot of my mistakes and as for the rest, well, I try not to introduce bugs But when I do, printf() is still my favourite method. It forces me to understand what I'm actually doing.

I also used Lint for a while, and it did catch some suspicious stuff in my code, but again I found that my time was better spent trying to learn to program properly. I suppose I'm kinda old school...

I'd tend to agree. Having worked on lots of annoying embedded systems with no sourcelevel debugging (or more or less flaky versions of gdb) I found it more productive to write code that works-if-it-compiles (static defensive programming techniques). While this is useless with dynamic languages, it is a lifesaver for C/C++. The result is I rarely need a debugger except as a last resort. Sometimes I just use it as a viewer for other debugging techniques deliberately placed in the program in case of faults.

Another good trick is to make sure your code compiles/runs on more than one target, so you can get access to source-level debugging if it really becomes necessary, or speeds up development (I hate to say it but VisualC still has the most productive one, for now). I suppose if you're using GEM this would not be very practical though.

[wongck]

I suppose if you're using GEM this would not be very practical though.

LOL... 25 yrs ago, GEM helped me break into Windows programming easily.
That's another story; I think I mentioned it before here.

[JustinPayne]

LOL... if you have 4 Gigs... that's definately more than enough for Mint.
I have less than that on my Falcon/CT63 system.
You mean 4MB I guess.

Ah yes, Eclipse was one of those IDE that I was going to use for debugging applications on the Falcon.
Just set that up as the gdb client and you should be able to do it.

LOL! Yes, I do that a lot these days. Gigs instead of megs. I was going to get a 14meg board but it just up in price to about $100 USDs with shipping and I just couldn't pull the trigger at this time.

I actually installed Netbeans as well since someone suggested it. I know I could have used Eclipse, but it was late and I'm also familiar with the JavaBeans IDE. I think what I need to figure out is how to do my debugging using a modern IDE like the WUDSN IDE for Eclipse. WUDSN is awesome for good ol' 8-dev development.

I'll look into setting up the gdb client. Thanks for the suggestion.

[wongck]

Picked up some chatter over the mint list channel. Last year someone talking about possibly new IDE for the Atari. Wonder how's that getting along.
May be JFL or Joska knows more of the on-goings there.

[jfl]

Picked up some chatter over the mint list channel. Last year someone talking about possibly new IDE for the Atari. Wonder how's that getting along.
May be JFL or Joska knows more of the on-goings there.

An IDE has been an on-and-off subject of conversation over the years. Not that I particularly care about that subject, though (my opinion being that it'll never happen I moved along).

[wongck]

An IDE has been an on-and-off subject of conversation over the years.

yeah, we did have a bash over here as well.
I was hoping that something will happen this time round as the folks over at MiNT list are movers and shakers in the Atari community and will normally makes things happen.