In a previous blog post, I had described the newly added ability to edit raw memory. While this makes a number of things possible that otherwise wouldn’t be, it generally isn’t the most convenient approach for the more general case one runs into over the course of debugging. As of hrev49449, some new enhancements have been introduced that should make life much simpler in many cases.
As an operating system that implements the POSIX specification, Haiku includes support for signals, and the requisite API calls for an application to decide how it will handle them. While these aren’t really used by the Be API in any meaningful way, they do frequently come into play for ported applications and libraries. Up until now, however, our debugger has lacked support for them, which could make debugging situations involving signals a less than convenient affair if one didn’t already know what to look for. As of hrev49356, this has been rectified.
As those who make regular use of it probably already know, one of the features of Haiku’s integrated debugger is the ability to inspect the contents of arbitrary (mapped) locations in the target team’s address space. This can be handy in various instances, such as when trying to track down bugs that are likely due to a piece of code overwriting part of another data structure, since the data that’s been written to memory might contain some pattern or even a familiar string that might hint at the culprit.
Since the last time, I’ve put a bit more work into improving the expression evaluator that was started as part of the sprint. Since some of its new capabilities are likely to be useful to others, and might not necessarily be obvious from simply reading the commit list, I thought I’d elaborate on them a bit here.
While I was unable to actually attend Begeistert this time around, I was nonetheless able to take some time off work to join in on the traditional during/post-BG code sprint. As per usual, this revolved around improving our integrated debugger.
This time around, we only have one or two new features to cover as such, since most of my time recently has been spent under the hood.
Some time has passed since my last post on the subject, and I keep finding time to work on it, so I thought another update on Debugger progress might be of interest. Most of the features added since my previous post are fairly minor, but should hopefully be interesting/useful nonetheless.
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.
As seen in Ingo's excellent presentation on Haiku's built-in debugging tools, our graphical debugger, while getting quite capable, is still missing a number of important features. As such, I made it my goal this week to try and resolve as many of those as I was able to.
