Debugging tools

Hi

I'm not new to the Amiga but I'm completely new to OS4 and the AmigaOne. Back in the day I used to write debugging tools and game disk operating systems for the A500 and A1200. Of course, this was all in 680x0...

In my intro post there was a comment made that OS4 is short of debugging tools - something I'd be really interested in working on, but I have some questions:

1. Is this true or are there good tools available?
2. Is it a case of improving existing tools - eg gdb - or is there a requirement for something amiga specific?
3. Before OS4 things were simple: it was just the 680x0 range to contend with - are things more complicated now or is any PPC processor much like the next one?
4. How easy is it to install low level processor trap handlers now? In my day it was all about patching the various vectors and resetting the VBR...

As you can see, I'm a bit new to the current platform so please go easy with your comments!

@apache64

Cant answer you about everything, but can say, that GDB for aos4 very buggy and if someone can fix it, it will be pretty cool.

The others what we have: memguard (and sashimi for redirect), all those snoopdos/snoopy utilityes, add2line (which give you possibility to detect by the stack trace, on which line of code crash is happenes). Into the os itself added some more stuff, which try to protect some memory areas, OS also trying detect now unfreed signals (and inform you in shell by words like "you have unfreed singnals"). "readelf" binary are here too (for better navigate over the ELF binaryes, like to understand use it static libs or dynamic, which headers/sections are inside, etc). OS itself have GrimReaper (some kind of in-build easy-little-memory-bug-catcher), which also works not so good, and from time to time can freeze the os completely. There is also "dumpdebugbuffer" binary, which can show you almost the same info as GR show (but in console, what can be better from time to time). Also some one are tryed to write "profiler", but its far from usable for now, and on some machines just does not works.

In other words , we have "something", but GDB buggy, and other tools are only for "something".

Few weeks ago, we start to talk about porting of Valgrind (the best debugging packet from unix world, which not only debugger, but a suite of tools for debugging and profiling, and many others which you can read on the official site here ).

But that port of course cant be just easy recompile and run, because it heavy based on the binary structures (good for us, aos4 also have ELF binaryes as wel => a bit easy), on memory layots and so on. Still, it possible to port of course (because there is MacOS port already, and support of different linuxes and freebsd and sunos), but it for sure need _real_ coder, who will works on it hard.

So, imho, if we will have on aos4 fully working version of GDB and port of Valgrind => nothing more is need it.

EDIT: i found in some old thread (where i ask about port of Valgrind), a message from "sba" member: here If you will be in interest, you can contact with him about.

@kas1e

Thanks for the comments. I've already found a PDF of the IBM E Book Specification (which appears to cover the PPC 440EP found on the SAM440EP motherboard) so that's a good start. From a quick flick through it looks quite similar to the MC680x0 series (most silicon does really at the machine code level).

Once I've got hold of my 440ep I'll take at look at the latest SDK and the tools you mention - hopefully that will give me a bit more to go on.

I think improving/finishing gdb might be a little out of my capabilities but I thought I might start with a process profiler (I know there are plenty already) as this will give me a chance to get used to exec and intuition again (most of my previous Amiga coding was direct to the hardware) and I can build from there.

I know this will sound stupid, but I'm guessing a useful debugger would be something which will allow you to launch your application and then step through the code / run to a specific point and also aim to catch exceptions?

Sounds daft I know but, as I say, my previous work had custom debuggers built-in but they were very rudimentary as there was no intuition running!

@apache64

Rather than implement everything from scratch, check out the IDebug interface of exec, and also the functions provided by elf.library. Some of these will no doubt help you in parsing the elf files.

Currently, OS4 and gcc supports both the dwarf2 and stabs debugging formats, both of which are quite well documented out in the wild.

Simon

@Rigo

Thanks - will do. All these new libraries and C++ interfaces to get used to!