Debugging?

MartinW · 26 August 2017, 13:05

General question...

If I'm writing in C and cross compiling (using gccv6), whats the generally accepted way of debugging program? Am I to assume that I copy it to real hardware and use a native debugger? In which case, any in particular?

At the moment on my native hardware (a GB-A1000 with 060) I am using StormC v3. I read a lot of bad things about it, but for someone just starting out, no matter how clunky it may be, the "IDE" is a great and fast way to get going. I've copied the install files for vbcc over to the machine but wasn't really intending to install it until something dictated the need.

I do also have FS-UAE running on the linux side of things that I use 75% of the time before trying on the real hardware.

Last night I had code that was crashing the minute I ran it on FS-UAE (software failure) so I built it on the Amiga with StormC but it didn't crash. It also didn't do anything, but it didn't crash. I tried to debug it, but of course, no crash meant that was kind of impossible.

The ideal would be remote debugging from within my linux based IDE (Jetbrains CLion). I'm sure I've seen remote debugging mentioned here in a search.

alkis · 26 August 2017, 14:46

I know this is not what you'd like to hear, but....lot's of printfs.

phx · 26 August 2017, 18:20

The debugger in UAE is quite low-level. But when your knowledge of 68k-assembler is good, then this is an option. It doesn't offer much comfort, though. Its main advantage is to be able to debug low-level stuff, which is otherwise impossible to debug (because you have taken over the system, for example). Otherwise, better use a debugger on real hardware.

Most Amiga compilers can include symbols in the final executable (HUNK_SYMBOL). And also some compilers (including vbcc) support the LINE DEBUG hunks, introduced by SAS/C, which offer you some minimal source level debugging. A debugger would be able to show you the current source for the code you are debugging. Any additional debugging information is usually compiler/debugger-specific.

Be prepared that you have to debug your code on the 68k level, even with native debuggers. When you have some symbols to set a breakpoint on a function, you are already lucky.

I am using BDebug from the Barfly assembler package, which is a nice, system-compliant, AmigaOS debugger. It supports symbols and source level debugging via HUNK_DEBUG/LINE.

But Alkis is right. Most of the time printf is the easiest way to go.

matthey · 27 August 2017, 01:58

Quote:

Originally Posted by MartinW

If I'm writing in C and cross compiling (using gccv6), whats the generally accepted way of debugging program? Am I to assume that I copy it to real hardware and use a native debugger? In which case, any in particular?

Some programmers are using GCC 6 with vlink (vbcc linker) which should give Amiga HUNK format and allow BDebug (Barfly) and CPR (SAS/C) debugging. Maybe others have GDB working?

Quote:

Originally Posted by MartinW

At the moment on my native hardware (a GB-A1000 with 060) I am using StormC v3. I read a lot of bad things about it, but for someone just starting out, no matter how clunky it may be, the "IDE" is a great and fast way to get going. I've copied the install files for vbcc over to the machine but wasn't really intending to install it until something dictated the need.

StormC v4 uses an old but good version of GCC.

Quote:

Originally Posted by MartinW

The ideal would be remote debugging from within my linux based IDE (Jetbrains CLion). I'm sure I've seen remote debugging mentioned here in a search.

GDB and CPR support remote debugging.

Quote:

Originally Posted by phx

I am using BDebug from the Barfly assembler package, which is a nice, system-compliant, AmigaOS debugger. It supports symbols and source level debugging via HUNK_DEBUG/LINE.

I prefer BDebug also for vbcc and SAS/C generated executables.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

Toni Wilen · 27 August 2017, 12:36

Also use enforcer-like program to instantly detect most invalid/null pointers. And in emulation you can also enable invalid access logging in addition to other debugging tools.

MartinW · 27 August 2017, 13:00

Thanks everyone for the comments. For a noob to the Amiga programming world there's a lot to take in and read up on but I have a good basis now for doing just that. All I need is time now

I'm a programmer of 25 years for a living incidentally so I'm no stranger to printf debugging - indeed even in the world of modern IDEs that we live in it's not uncommon that I have to resort to that. It simply didn't occur to me that using printf's would automatically pop open a window with STDOUT in it.

alkis · 27 August 2017, 14:11

This is related: http://eab.abime.net/showthread.php?t=80894

MartinW · 27 August 2017, 22:29

Nice - that's an interesting way of tackling things. I'm not so interested in being able to see the Amiga programs output in the Linux term because, let's face it, if I'm running the program on the Amiga (real or emulated) then I can see it in the window on the Amiga just as easily (split screen or multi screen).

What had already occurred to me however was to write a small resident program on the Amiga side which listened to the serial port and waited to be told what to do. Commands could be things like "run this program". That way my Linux build script can write it's output to a folder that is mapped on the Amiga to "PCDATA:" and then a command can be sent over serial to tell the Amiga to run it. Another command could tell it to kill it.

Only works if the program you want to remotely run doesn't take over the OS of course, and a lot of this is pointless if the program you're writing for the Amiga requires user interaction, because then you'll have to switch to the Amiga and input stuff anyway.

All useful info however!

nogginthenog · 28 August 2017, 15:32

Quote:

Originally Posted by MartinW

What had already occurred to me however was to write a small resident program on the Amiga side which listened to the serial port and waited to be told what to do. Commands could be things like "run this program". That way my Linux build script can write it's output to a folder that is mapped on the Amiga to "PCDATA:" and then a command can be sent over serial to tell the Amiga to run it. Another command could tell it to kill it.

You can run an Amiga shell over a serial connection and send shell commands. Not sure how you would kill a process but I'm sure there is a tool out there (Scout?).

Code:

newcli aux:

Or you can do it over a TCP/IP if your Amiga is networked.

nogginthenog · 28 August 2017, 15:33

BTW, what is the status of GDB on the Amiga? I saw a GDB stub for AROS but I never tried it.

cla · 03 January 2018, 20:59

Quote:

Originally Posted by nogginthenog

BTW, what is the status of GDB on the Amiga? I saw a GDB stub for AROS but I never tried it.

The only version I have been able to dig up:
http://aminet.net/package/dev/gg/gdb-bin

Maybe the last.

26 August 2017, 13:05	#1
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Debugging? General question... If I'm writing in C and cross compiling (using gccv6), whats the generally accepted way of debugging program? Am I to assume that I copy it to real hardware and use a native debugger? In which case, any in particular? At the moment on my native hardware (a GB-A1000 with 060) I am using StormC v3. I read a lot of bad things about it, but for someone just starting out, no matter how clunky it may be, the "IDE" is a great and fast way to get going. I've copied the install files for vbcc over to the machine but wasn't really intending to install it until something dictated the need. I do also have FS-UAE running on the linux side of things that I use 75% of the time before trying on the real hardware. Last night I had code that was crashing the minute I ran it on FS-UAE (software failure) so I built it on the Amiga with StormC but it didn't crash. It also didn't do anything, but it didn't crash. I tried to debug it, but of course, no crash meant that was kind of impossible. The ideal would be remote debugging from within my linux based IDE (Jetbrains CLion). I'm sure I've seen remote debugging mentioned here in a search.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Source Debugging + Linker?	wk_end	Coders. Asm / Hardware	3	21 April 2016 13:40
Debugging vbcc code	tolkien	Coders. C/C++	5	14 February 2015 06:45
Debugging on the real device	neoman	Coders. Asm / Hardware	2	08 May 2014 22:47
Remote C/C++ debugging?	alkis	Coders. C/C++	1	03 January 2014 12:17
Enforcer debugging tool	M&F	support.WinUAE	0	21 May 2002 22:53

26 August 2017, 14:46	#2
alkis Registered User Join Date: Dec 2010 Location: Athens/Greece Age: 53 Posts: 719	I know this is not what you'd like to hear, but....lot's of printfs.

26 August 2017, 18:20	#3
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	The debugger in UAE is quite low-level. But when your knowledge of 68k-assembler is good, then this is an option. It doesn't offer much comfort, though. Its main advantage is to be able to debug low-level stuff, which is otherwise impossible to debug (because you have taken over the system, for example). Otherwise, better use a debugger on real hardware. Most Amiga compilers can include symbols in the final executable (HUNK_SYMBOL). And also some compilers (including vbcc) support the LINE DEBUG hunks, introduced by SAS/C, which offer you some minimal source level debugging. A debugger would be able to show you the current source for the code you are debugging. Any additional debugging information is usually compiler/debugger-specific. Be prepared that you have to debug your code on the 68k level, even with native debuggers. When you have some symbols to set a breakpoint on a function, you are already lucky. I am using BDebug from the Barfly assembler package, which is a nice, system-compliant, AmigaOS debugger. It supports symbols and source level debugging via HUNK_DEBUG/LINE. But Alkis is right. Most of the time printf is the easiest way to go.

27 August 2017, 12:36	#5
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Also use enforcer-like program to instantly detect most invalid/null pointers. And in emulation you can also enable invalid access logging in addition to other debugging tools.

27 August 2017, 13:00	#6
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Thanks everyone for the comments. For a noob to the Amiga programming world there's a lot to take in and read up on but I have a good basis now for doing just that. All I need is time now I'm a programmer of 25 years for a living incidentally so I'm no stranger to printf debugging - indeed even in the world of modern IDEs that we live in it's not uncommon that I have to resort to that. It simply didn't occur to me that using printf's would automatically pop open a window with STDOUT in it.

27 August 2017, 14:11	#7
alkis Registered User Join Date: Dec 2010 Location: Athens/Greece Age: 53 Posts: 719	This is related: http://eab.abime.net/showthread.php?t=80894

27 August 2017, 22:29	#8
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Nice - that's an interesting way of tackling things. I'm not so interested in being able to see the Amiga programs output in the Linux term because, let's face it, if I'm running the program on the Amiga (real or emulated) then I can see it in the window on the Amiga just as easily (split screen or multi screen). What had already occurred to me however was to write a small resident program on the Amiga side which listened to the serial port and waited to be told what to do. Commands could be things like "run this program". That way my Linux build script can write it's output to a folder that is mapped on the Amiga to "PCDATA:" and then a command can be sent over serial to tell the Amiga to run it. Another command could tell it to kill it. Only works if the program you want to remotely run doesn't take over the OS of course, and a lot of this is pointless if the program you're writing for the Amiga requires user interaction, because then you'll have to switch to the Amiga and input stuff anyway. All useful info however!

28 August 2017, 15:33	#10
nogginthenog Amigan Join Date: Feb 2012 Location: London Posts: 1,309	BTW, what is the status of GDB on the Amiga? I saw a GDB stub for AROS but I never tried it.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)