Is there someone that managed to use GDB from the latest public SDK under AOS 4.1u1 ? For me I only get crash (see crash log) each time I'm trying loading symbols. I tried rebooting under my previous OS 4.1 installation and it works like a charm (that is like we are used to, i.e. not as well as under other OS but yet can help debugging). It seems the crash occurs in a newlib call...
Newlib and binutils were updated so it probably explains the crashes of GDB.
It's strange to see not every developer needs GDB. It's a so useful tool. And if some ex-developer come back to the platform, I hope he won't be disappointed not to have GDB.
It was madness buggy even without update1, i don't know how you use it before .. So i think not many of us miss it, because not many of us ever can use it normally (that imho of course).
in fact if you are not used to it and only to SAS/C debugger it's surely a big shock. Anyway even if it crashes from time to time when you stayed in your own code (i.e. not trying to step into system's code) it was basically working. Oh and there was a time (around 2005) when this debugger was rock stable too back things evolved in the system without taking care of maintaining the port
I have most experience with Windows based debuggers (both userland and kernel) but I am using gdb under Linux/BSD systems often too and I agree that if one is coming from different tool it is a big change. Anyway from my perspective on AOS it was simply unstable. Not that I had a lot of experience with it and SDK. I've just recently started to play with it - found out it had problems and left it right there.
Yes you are right it's really a shame that it wasn't updated because between AOS4 pre1 up to pre3 (or was it pre4?) it worked really good. Anyway it is(was until this update1) still of great help to see how things are going if only you took time to set breakpoints at interesting places. I convey that doing a real step debugging session how you (or me) are used to do elsewhere isn't very easy and prone to crash :-/
So it looks like GDB need to recompile with all new libs/includes. Hope Hyperion will take a look on it for next SDK update (i in interst about stable-working gdb too).
And none of these bountes have soruce code of the current GDB for os4. Because starting for scratch it will be huge job imho (fixing the same bugs which hyperion fixed whyle port it , etc).
you understood wrong : this repository is named 'ADT' for 'Amiga Development Tools' as such verything that is in the repository is for use in AmigaOS 4.
The fact that it doesn't work all that well, and that it doesn't have a GUI means that most people have learnt how to work without it.
If it were integrated into an IDE (e.g., CodeBench), then I'd use it extensively. However, their's no point in Rigo even starting on that if GDB doesn't work reliably.
Any discussion on which open-source GUI frontend for GDB, or if a from-scratch new GUI is preferred, should the relevant bounty be opened? I posted a quick list of existing open-source frontends I found on wikipedia in the bounty comments. It's probably not complete.
They must have it - at least SDK in some form because how they would compile the final version of OS? Would be interesting to hear from Hyperion what are they using for debugging.
Any discussion on which open-source GUI frontend for GDB, or if a from-scratch new GUI is preferred, should the relevant bounty be opened? I posted a quick list of existing open-source frontends I found on wikipedia in the bounty comments. It's probably not complete.
To be honest, I'd prefer it if CodeBench had support for GDB built in rather than having a separate GUI. Of the ones in your list, the only one that I have used is Eclipse, and that is a full IDE.
For me, the highest priority would be getting GDB working properly, which must include the network backend that the GUIs use to control it.