More blogs in Arm Community blogs
Tags
Actions
Related blog posts
Related forum threads

Software Debuggers: What next?

Andrew N. Sloss
1 minute read time.

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?

Anonymous

  • Hi nemo20000, you may be interested in having a look this Application Rewind in DS-5. Let me know what you think...

  • 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?
  • 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.
  • Thank you for your comments! Totally agree "rewinding and multithreaded" are important base technologies, but the problem is how to scale these capabilities effective across 16, 32, or even greater that 128 cores on-chip. Problems around debugging "many" core heterogeneous systems is going to be critical and difficult. An important question to ask is do you think/believe the current debugger UIs are sufficient and capable of handling these scenarios? Personally I see a problem looming and unless we think about this problem in a very different way we will not scale. Do you agree or disagree? Again thank you for comments it is going to be an interesting area for the future.
  • 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.
Tools, Software and IDEs blog