Help debugging VBCC output...

[Jose]

Hi, can someone advise on a good debugger to go with VBCC ? I tried the SASC debugger with the output of the following VBCC invocation: vc sourcename -c99 -cpp-comments -ljpeg -lamiga -O0 -g -no-delayed-popping

Also tried VBCC with the -hunkdebugg (or something) option but the SASC debugger doesn't load anything....

Anyway, if there's another good one other than SASC's it would be cool, as SASC is not developed anymore.
BTW, never used GCC, maybe there's a good debugger with it, I'd use it as long as I don't have to spend hours learning the syntax of line commands and it's cli outputs...

[Jose]

BUMP

Sorry I really need help on this... :-o

I also tried with the backend specific -debug= VBCC option but neither SASC's debugger nor GDB recognize the output.

I also tried the -hunkdebug option on both, no results either.

BTW the VBCC manual is a bit vague on the -debug= option as it doesn't speficy the numbers one should use.

This is getting frustrating.... I'm using printf 's all the way to try to find a bug but a source level debugger would be so much better as I could easily see the variables ...
 :pissed:

[Karlos]

Sorry, I tend to go for serial line level debugging at a source level rather than using debugging software (other than mungwall and enforcer).

[Jose]

@Karlos

Never messed with that, but anything's better than this..:lol:  
How does it work, it outputs the line number being executed ? What software do you use ? Can VBCC be used for that ? Is it possible to check variable's values like that ?...
 

[Karlos]

The first thing I do is to go through my code very closely and with a lot of coffee. I find this eliminates 95% of problems.

Serial line debugging is just using functions like debuglib/KPrintF() (sends data to the serial port, which can be intercepted with tools like sushi or a terminal on a null modem link since it is not always possible to use printf() or fprintf() functions.

Stuff like enforcer and mungwall just let you spot illegal memory accesses which in my experience are almost always down to oversights with pointers.

[Jose]

Hmm, ok. But still miss a source level debugger. Going through big parts of code is a pain, a debugger would allow me to check each variable status just before a crash or something went wrong, and have a good clue where the problem is after that. At least when the bug lies in logic and not some pointer misuse, this helps a lot .. Not that I have much experience anyway... I was using SASC's debugger but can't use it cause I'm using the ISO 99's long long type and SASC can't compile that and it doesn't recognize vbcc's debug output..