Great leaps in human knowledge are linked to advancements in tools. For software engineers the debugger is a cornerstone tool to create reliable products. We engage in a running battle fighting both the problem and the tool because each debug situation is unique. This is a major challenge for debugger designers, i.e. how do we build a debugger with a balance of flexibility and simplicity with enough usefulness? With the rate of hardware change increasing – along with improvements in Operating Systems and Programming Languages, debugging and optimizing software becomes paramount i.e. improving performance, code-size and energy-efficiency.
As we transition towards more hardware parallelism the pressure grows to keep the time-to-market at least constant which in turn means new debugging strategies. From my perspective it is always good to draw from the current technology landscape and view how we can use these technologies in the future. For instance, Cover Flow UI could be used to improve multi-processor viewing, Microsoft Kinect to navigate the debug UI, and further more expert systems running in the cloud to help analyze problems and bottlenecks in the code. These ideas may be farfetched but we need to start looking at alternative ways of making debug and optimization more efficient in the future – if we want to keep the time-to-market constant.
Today we see mobile and tethered systems with 1, 2 and soon to be 4 application processors in the compute-node. Tomorrow this number could be exponentially larger either in an off-chip distributed configuration and/or on-chip tightly integrated configuration. Taking just performance as one of the metrics for the future - performance will be a function of how well the data can be localized and how an algorithm can be broken down into parallel tasks. The software that runs on these types of systems will have to be debugged and optimized using radically new techniques due to the inherent complexity.
Tomorrows debuggers will be different because tomorrows hardware topologies will be different. The question is what other farfetched technologies are required to make the debug process easier?
Andrew N. Sloss, Consultant Engineer, ARM, He is interested in future software technologies and trends. In particular, Andrew looks at how software can make use of low power devices in new innovating ways. Andrew is an author, Fellow of the British Computer Society, and currently holds the chair of the ARM Bindings Sub Team for UEFI.
All company and product names appearing in the ARM Blogs are trademarks and/or registered trademarks of ARM Limited per ARM’s official trademark list. All other product or service names mentioned herein are the trademarks of their respective owners.
5 Comments On This Entry
Please log in above to add a comment or register for an account
Page 1 of 1
armv9
22 November 2011 - 03:49 PM
The source of errors could be as mysterious as the source of progress and innovation sometimes.
nemo20000
23 November 2011 - 03:07 PM
Cover Flow? Kinect? I hope that’s a joke. What I need in a debugger is the ability to rewind – to go back from the point that the problem becomes apparent to where it was caused. These days it is also necessary to be able to reproduce behaviour in a multithreaded, multicore system – bug reports are useless if they cannot be reproduced never mind investigated. Solve those problems – rewinding and multithreaded repeatability – then worry about graphical frippery and hand waving nonsense.
algrant
29 November 2011 - 12:07 PM
Let's stop thinking about "debuggers"! The problem here is how to observe and visualize systems and bridge the gap between silicon speeds and complexity, and what humans can cope with. Whether we're finding bugs, finding performance bottlenecks, predicting next-generation requirements, coverage testing, even intrusion detection, that's just the top layer. Many of the basic (and difficult) scaling, communication, data management and visualization problems are common.So, a Kinect interface would be nice (a bit like "Minority Report") but let's not tie it to preconceived ideas of an end goal.
Hobson Bullman
30 November 2011 - 12:55 PM
Balancing flexibility and simplicity with usefulness... ...that's a great way of explaining the problem, Andrew. All too often debuggers (well, tools in general) provide either great ease of use but not enough flexibility, or uber-flexibility but are really hard to learn and use. One approach we've taken in DS-5 Debugger recently is to take advantage of the new ways of customisation that are offered by things like jython: essentially, we can expose scripting interfaces that are very tightly coupled to the capabilities of the debugger, to allow a controlled way of extending the functionality of the product. I'm really interested in seeing whether this helps the flexibility/usability balance.Oh, and I agree with nemo20000's specific point about the usefulness of rewind debugging: do you have a specific case in mind where this would have helped you?
Page 1 of 1
»
Blog Tags
»
Search My Blog
»


5 Comments











