Debugging: Difference between revisions

Revision as of 09:36, 11 June 2023

Revision as of 15:56, 6 August 2023

Line 53:

* ''[[Time travel debugging]]'' is the process of stepping back in time through source code (e.g. using [[Undo (company)|Undo LiveRecorder]]) to understand what is happening during execution of a computer program; to allow users to interact with the program; to change the history if desired and to watch how the program responds.

* ''[[Delta Debugging]]''{{snd}} a technique of automating test case simplification.<ref>{{cite book |last=Zeller |first=Andreas |date=2005 |title=Why Programs Fail: A Guide to Systematic Debugging |publisher=Morgan Kaufmann |isbn=1-55860-866-4}}</ref>{{rp|p.123}}<!-- for redirect from 'Saff Squeeze' -->

* ''Saff Squeeze''{{snd}} a technique of isolating failure within the test using progressive inlining of parts of the failing test.<ref>{{cite web|url=http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|archive-url=https://web.archive.org/web/20120311131729/http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|url-status=dead|archive-date=2012-03-11|title=Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze}}</ref><ref>{{cite web |last1=Rainsberger |first1=J.B. |title=The Saff Squeeze |url=https://blog.thecodewhisperer.com/permalink/the-saff-squeeze |website=The Code Whisperer |date=28 March 2022 |access-date=28 March 2022}}</ref>

* ''Causality tracking'': There are techniques to track the cause effect chains in the computation.<ref>{{cite journal|last=Zeller|first=Andreas|date=2002-11-01|title=Isolating cause-effect chains from computer programs|journal=ACM SIGSOFT Software Engineering Notes|volume=27|issue=6|pages=1–10|doi=10.1145/605466.605468|s2cid=12098165|issn=0163-5948}}</ref> Those techniques can be tailored for specific bugs, such as null pointer dereferences.<ref name="BondNethercote2007">{{cite book |last1=Bond|first1=Michael D.|title=Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07|last2=Nethercote|first2=Nicholas|last3=Kent|first3=Stephen W.|last4=Guyer|first4=Samuel Z.|last5=McKinley|first5=Kathryn S.|chapter=Tracking bad apples|year=2007|pages=405|doi=10.1145/1297027.1297057|isbn=9781595937865|s2cid=2832749}}</ref>

Line 59:

In contrast to the general purpose computer software design environment, a primary characteristic of embedded environments is the sheer number of different platforms available to the developers (CPU architectures, vendors, operating systems, and their variants). Embedded systems are, by definition, not general-purpose designs: they are typically developed for a single task (or small range of tasks), and the platform is chosen specifically to optimize that application. Not only does this fact make life tough for embedded system developers, it also makes debugging and testing of these systems harder as well, since different debugging tools are needed for different platforms.

Despite the challenge of heterogeneity mentioned above, some debuggers have been developed commercially as well as research prototypes. Examples of commercial solutions come from [[Green Hills Software]],<ref>{{cite web|url=https://www.ghs.com/products/supertraceprobe.html|title=SuperTrace Probe hardware debugger|website=www.ghs.com|access-date=2017-11-25|archive-date=2017-12-01|archive-url=https://web.archive.org/web/20171201031136/https://www.ghs.com/products/supertraceprobe.html|url-status=live}}</ref> [[Lauterbach GmbH]]<ref>{{cite web|url=https://www.lauterbach.com|title=Debugger and real-time trace tools|website=www.lauterbach.com|access-date=2020-06-05|archive-date=2022-01-25|archive-url=https://web.archive.org/web/20220125072945/https://www.lauterbach.com/frames.html?home.html|url-status=live}}</ref> and Microchip's MPLAB-ICD (for in-circuit debugger). Two examples of research prototype tools are Aveksha<ref>{{cite journalbook|last1=Tancreti|first1=Matthew|last2=Hossain|first2=Mohammad Sajjad|last3=Bagchi|first3=Saurabh|last4=Raghunathan|first4=Vijay|date=2011|title=Aveksha: A Hardware-software Approach for Non-intrusive Tracing and Profiling of Wireless Embedded Systems|journal=Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems |chapter=Aveksha |date=2011|series=SenSys '11|___location=New York, NY, USA|publisher=ACM|pages=288–301|doi=10.1145/2070942.2070972|isbn=9781450307185|s2cid=14769602}}</ref> and Flocklab.<ref>{{cite journalbook|last1=Lim|first1=Roman|last2=Ferrari|first2=Federico|last3=Zimmerling|first3=Marco|last4=Walser|first4=Christoph|last5=Sommer|first5=Philipp|last6=Beutel|first6=Jan|date=2013|title=FlockLab: A Testbed for Distributed, Synchronized Tracing and Profiling of Wireless Embedded Systems|journal=Proceedings of the 12th Internationalinternational Conferenceconference on Information Processingprocessing in Sensorsensor Networksnetworks |chapter=FlockLab |date=2013|series=IPSN '13|___location=New York, NY, USA|publisher=ACM|pages=153–166|doi=10.1145/2461381.2461402|isbn=9781450319591|s2cid=447045}}</ref> They all leverage a functionality available on low-cost embedded processors, an On-Chip Debug Module (OCDM), whose signals are exposed through a standard [[JTAG|JTAG interface]]. They are benchmarked based on how much change to the application is needed and the rate of events that they can keep up with.

In addition to the typical task of identifying bugs in the system, embedded system debugging also seeks to collect information about the operating states of the system that may then be used to analyze the system: to find ways to boost its performance or to optimize other important characteristics (e.g. energy consumption, reliability, real-time response, etc.).

Line 73:

* Detecting and penalizing debugger<ref name="soft-prot"/>

An early example of anti-debugging existed in early versions of [[Microsoft Word]] which, if a debugger was detected, produced a message that said, "The tree of evil bears bitter fruit. Now trashing program disk.", after which it caused the floppy disk drive to emit alarming noises with the intent of scaring the user away from attempting it again.<ref name="SecurityEngineeringRA">{{cite book |url=https://archive.org/details/securityengineer00ande |url-access=registration |author=Ross J. Anderson |title=Security Engineering |isbn=0-471-38922-6 |page=684 |author-link=Ross J. Anderson |date=2001-03-23 |publisher=Wiley }}</ref><ref name="toastytech">{{cite web |url=http://toastytech.com/guis/word1153.html |title=Microsoft Word for DOS 1.15 |access-date=2013-06-22 |archive-date=2013-05-14 |archive-url=https://web.archive.org/web/20130514033750/http://toastytech.com/guis/word1153.html |url-status=live }}</ref>

==See also==