- Hello from the new Haiku website!
- Haiku monthly activity report - 12/2016
- UEFI Progress Update
- Haiku monthly activity report - November 2016
- A little report on Capitole du Libre
- Haiku monthly activity report - October 2016
- Haiku monthly activity report - September 2016
- Haiku monthly activity report - August 2016
- Tales of a Video Editor #2
- Site issues / Potential upgrade
Debugger: Overview of New Features
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.
Return ValuesA feature that's been on my todo list for quite some time is retrieving and displaying function return values. This can be quite handy when stepping over code where the return value is used inline without actually being separately stored anywhere. An example would be when a function is called within a loop condition to determine if that loop should continue to execute or not, as shown below:
It can also handle when multiple values are returned in a single statement, i.e. when adding together the values returned by several different calls.
Improved typecastsAs some of you may recall from my previous post on this topic, during the last Haiku code sprint, the debugger gained the ability to enact simple typecasts on variables. However, one thing that was not supported which is quite often needed is typecasting to an array type. A simple example would be the argument array that's passed into main(). In its default state, the variable is of somewhat limited use, but fortunately we know its size, and as such can coerce it into something more helpful:
This supports multiple dimensions as well, so it can be applied in a number of circumstances.
Array RangesStill on the subject of arrays, and container types in general, a limitation of the debugger up until now is, when confronted with such a type, it would restrict itself to displaying at most the first 10-20 elements of it. This was partly done for sanity reasons, as, if you hypothetically have a container with a few thousand elements in it, expanding that to all its elements immediately would be a) time/memory consuming, and b) likely not all that helpful. However, until now there hasn't been a way to fine-tune the range that's displayed, since chances are the elements of interest are somewhere other than said initial elements. This has now been addressed, as shown below:
The BObjectList in question contains 1000 elements, of which only the first 20 are shown. We can now do the following to change that though:
As shown, the feature supports specifying an arbitrary list of subranges from the array/container, which can be quite handy if you need to be able to compare elements that are otherwise quite far apart. Another set of improvements that have been made which won't be quite as user-visible are a number of improvements to our crash reports. They now also show area/semaphore information for the crashed team, and have had their format improved to be a bit easier to follow/analyze. As always, I'll continue to work on further improvements as time permits. Hopefully the above are found helpful, and if any problems are found, please report them via our bug tracker.