“In the past few weeks, I’ve managed to find a bit more free time to work on Haiku. As per usual, the lion’s share of this time was spent on improving our integrated debugger. As such, I thought I’d give a brief overview of what’s been added, and how it can be useful.”
Oh, how many fun days and nights I spent hunched over my PowerMac sporting a 15″ CRT running BeOS, stepping through code in the Metrowerks debugger. I think the BDB was fairly similar on Intel. This looks sweet – very nostalgic for me.
Edited 2013-05-02 10:59 UTC
I would have to admit that my memories of bdb on Intel mostly involve it crashing a lot. Didn’t really experience the Metrowerks/PPC side of things myself. Glad you enjoyed that post in any case
Because the PowerPC side of things leveraged the Metrowerks compilers, it was “kind of different” but the same. BDB looked an awful lot like the MW debugger from what I remember. I seem to recall that the later version of BDB was more stable than the one that came with R5, and you needed to download that from Be directly back in the day.
Yeah, my debugger is pretty worthless. The first problem is user I have 640×480 screen size (too small). The second problem is the way I draw the window involves a callback from a “window manager” task. If you put a break point in you draw routine, it stops all updates of the screen!
The only good thing is I have a single-address map for all tasks. It can convert addresses to symbolic strings really easily.
<chuckle>I use printf debugging!
Showing return values of called functions is just awesome. Recently I’ve been using Netbeans and Eclipse (to work on Java, Android and PHP) and neither of them can do that (or perhaps I didn’t figure it out yet – I didn’t think it was possible, actually).
I have to try this thing out as soon as possible. Sadly, it’s been years since I have done some serious work in C++, my favourite language (call me mad).
Delphi’s integrated debugger has been doing that for years, and yes it is an awesome feature. I moved to Free Pascal development in recent years, where they use GDB as the debugger. Unfortunately GDB (with the Object Pascal language at least) can’t do that either, and it is very frustrating.
One of the shortcomings (or features, depending on the perspective) of GDB is that it expects some knowledge of the underlying architecture. On x86, for example, you just need to inspect the content of the EAX register for that context, which should hold the function’s return value (in most cases.)
Anyone remember borland’s dos turbo debuggers? They had the best debuggers by a long shot. It had syntax highlighting, flawless assembly & source code stepping, language variable awareness for watches, even remote debugging. Best of all it was very easy to use. I still curse every time I have to use gdb (even with a front end like ‘ddd’), it is horrific. After all these years, I’m still looking for a debugger under linux that’s remotely as good, something designed to work with assembly code. Has anyone else found something good?
Yes, there are many debuggers, but for other languages: like Java or C# have both excellent debuggers. If you want a good debugger for C++, GDB sometimes it works well if you use Eclipse’s CDT or QtCreator (both offer a good frontend with threads/variables, etc.)
If you use kde try kdbg. For usual tasks it works great. There is nemiver for gtk, but I have not used it that much. For binaries there is edb but, frankly, I stopped debbuging binaries years ago.
Anyway, you will find that most IDEs now have integration with gdb (geanny, codeblocks, kdevelop, qt-creator, eclipse and “kate”, the last through plugin).
acobar,
“Anyway, you will find that most IDEs now have integration with gdb (geanny, codeblocks, kdevelop, qt-creator, eclipse and ‘kate’, the last through plugin).”
It’s a good list everyone’s coming up with, thanks! I’d never heard of geanny, to be honest I don’t want a new editor or IDE. I’d hesitate to use a kate debugger for the same reason, ideally I’d prefer a standalone debugger, much like gdb itself but with a good UI. Never the less I might try some of these text editors to see how suitable they are for debug work. BTW Codeblocks was my favourite of those in your list for C development.
Edit:
Back in the day for windows kernel developement, IDA Pro was pretty good, they’re supposed to support linux now, but unless they changed they tarnished the product with DRM and even the starter edition costs a thousand dollars.
Edited 2013-05-02 19:06 UTC
I found a debugger called “edb”.
http://codef00.com/projects#debugger
It’s a true standalone assembly debugger. It’s got a simplistic feature set, but it works so it’s worth adding to the list.
Purely out of curiosity, may I ask what it is you work on that requires regularly dealing with assembly?
anevilyak,
“Purely out of curiosity, may I ask what it is you work on that requires regularly dealing with assembly?”
Actually it’s not very regularly. The last all-assembly project I did may have been 5 years ago. Now a days I use it more for microbenchmarking and optimization here and there, specifically in terms of cryptographic function implementations. It’s much faster and less error prone to use an assembly debugger to visualize and step through code flows instead of trying to keep track of everything on paper, especially when comparing to code outputted by a compiler.
Eclipse CDT or QtCreator. It has been a long time since I touched KDevelop, so I don’t know how it behaves nowadays.
Having had the chance to start developing software around 1986 while trying out quite a few development environments, I fail to understand how many developers like to develop in UNIX as if they were using System V!
Talk about time travel.
GDB has a very nice feature though, you can use it as a C/C++ REPL while the programming is running.
It was quite helpful in a project where I was doing a lot of low level stuff.
moondevil,
“Having had the chance to start developing software around 1986 while trying out quite a few development environments, I fail to understand how many developers like to develop in UNIX as if they were using System V!”
Can you clarify what you mean?
“GDB has a very nice feature though, you can use it as a C/C++ REPL while the programming is running.”
You could watch & execute expressions in turbo debugger as well, dereference variables from pointers/structures. I cannot recall the full extent of the capability, and anyways it only applied to C & pascal (whereas I was using it more for assembly debugging). I vaguely remember being able to enter new assembly opcodes on the fly, although that might have only been debug.com.
“Eclipse CDT or QtCreator.”
I guess it’s time for me to try eclipse again, the last time I used it for a work project it was very bloated and slow.
I mean using shell + (vi | emacs) is today no different than when I used UNIX for the first time in 1994.
Maybe the only difference is that GNU tools tend to be more user friendly than the POSIX ones, specially in commercial UNIX systems.
Other than that, the setup is still the same.
Whereas a powerful IDE offers code navigation, background compilation, static analysis while you type, graphical display of data structures, semantic refactoring and many other things.
I used up to Turbo Pascal for Windows 1.5 and Turbo C++ for Windows 3.1, and don’t remember a REPL like functionality, then again, maybe I just missed it.
I like CDT’s CODAN, makes C feel like Pascal, in terms of safety.
Have you tried the cgdb frontend? http://cgdb.github.io/
linux-lover,
“Have you tried the cgdb frontend? http://cgdb.github.io/“
No I had not, if it works well that could permanently replace all my use cases for ever invoking gdb directly. I’m not particularly fond of having to type gdb commands into a debugger, but maybe I am biased towards the interfaces I learned with.
… that is a common occurrence, we tend to associate the first tool we learn with the “essence” of the task.
This makes me want to switch to Haiku just so I can use this debugger.
Thanks! I would have to caution that there are still quite a few things left to do feature-wise, though I’d like to think it’s generally day-to-day usable at this point.
Edited 2013-05-02 20:41 UTC
I used ‘ups” to work on a debugging network daemons (in particular, Merit Computer Network’s RADIUS server, based on the Livingston code). It offered a very nice way to view the code and step through it, etc. as you would expect a debugger to do, and to hold various various variables (including structures) in view at the same time.
Since I haven’t done C/C++ coding on that scale (several hundred thousand lines of code) for network daemons for some time, I’ve been satisfied with “gdb” when I need to.
Most of my coding since then has been without the aid of debugging tools since it’s involved scripted languages from web servers, cron jobs, etc. where I can’t attach a debugger and have to suffer with the equivalent of scattering “printf” statements through the code, guarded by a “debug_level” variable. (Sad and tedious.) I miss “ups”.
Actually, you can, but, as with all regular debugging, you will need a cup of coffee to bear the slowness of the process. If you use bash, there is bashdb. From the same author there is a debugger for perl and links on bashdb site to a ruby debugger. PHP has some debuggers as also Python so, actually, there is a chance you will be served by a debugger for your language of choice.
Regardless, I find it really handy to have “print/echo” macros on the critical parts of my code, no matter what was used. As developers, most of the times we have a good insight on where things can go wrong and start to wreak havoc. For me it is usually faster this way to spot, or at least narrow the boundaries of, where things got crazy.