Universal Debugger Project - Revision history

Parasyte: /* Preparation */

2010-10-21T07:38:52Z

‎Preparation

Parasyte: /* Development */

2010-10-21T07:35:51Z

‎Development

Parasyte: /* Terminology */

2009-07-24T06:05:45Z

‎Terminology

Parasyte: /* See also */ UDP -> SRDP

2009-04-21T23:47:52Z

‎See also: UDP -> SRDP

Parasyte at 03:20, 3 February 2009

2009-02-03T03:20:30Z

Parasyte: /* Development */ Updated

2009-01-27T00:31:59Z

‎Development: Updated

Parasyte: /* Preparation */ minor fixes and adjustments

2009-01-27T00:19:03Z

‎Preparation: minor fixes and adjustments

Parasyte: /* Encouraging community activity */ plurality

2009-01-17T21:37:06Z

‎Encouraging community activity: plurality

Parasyte: /* Encouraging community activity */ spelling

2009-01-17T21:32:50Z

‎Encouraging community activity: spelling

Parasyte: /* Advanced debugging technologies */ plurality

2009-01-17T21:26:49Z

‎Advanced debugging technologies: plurality

@@ Line 370: / Line 370: @@
 This use of the Gecko layout engine provides some unique advantages: First, it makes the disassembler super-portable; no need to rewrite platform-specific custom controls that do difficult text layout and line drawing code, not to mention making it all editable. Second, it provides the perfect means to be styled by the user (CSS) any way she likes, and it will always look the same, no matter which operating system it runs on (with the exception of, perhaps, which fonts are installed and which are used by the CSS). Finally, it provides dynamic control over the content via Javascript and DOM manipulation, once again in a completely platform-independent way.
-The final element of preparation is defining the naming conventions. It would be unwise to stick to "Universal Debugger Project" and "Universal Debugger Protocol" because as Lazy|Bastard of [http://www.gshi.org GSHI] publicly points out, the acronym UDP is already synonymous with the popular [http://en.wikipedia.org/wiki/User_Datagram_Protocol User Datagram Protocol]. He goes on to suggest a surrogate for the term "universal" (which is inaccurate at best; think "universal remote") with the more appropriate term "versatile". The naming of the project and protocol should be independent and chosen by their respective core contributors.
+The final element of preparation is defining the naming conventions. It would be unwise to stick to "Universal Debugger Project" because as Lazy|Bastard of [http://www.gshi.org GSHI] publicly points out, the acronym UDP is already synonymous with the popular [http://en.wikipedia.org/wiki/User_Datagram_Protocol User Datagram Protocol]. He goes on to suggest a surrogate for the term "universal" (which is inaccurate at best; think "universal remote") with the more appropriate term "versatile". The naming of the project and protocol should be independent and chosen by their respective core contributors. [[Scalable Remote Debugger Protocol]] is the name chosen for the protocol.
 The project and protocol will each have a healthy start without settling on a name early on, but I might recommend that, at the very least, temporary code-names are chosen so that they may be referred to during the early development stages. I have no reservation on code-names, so any suggestions would be appreciated. As a final word on project naming, I realize that brands are important. Having an easily recognizable and understandable name will become a priority as the project starts coming into fruition.

@@ Line 378: / Line 378: @@
 Initial development requires a great deal of effort. First, I will need a version control system that can handle a fairly large project with a fairly large number of developers. I've decided to go with [http://www.selenic.com/mercurial/wiki/ Mercurial].
-I would then devise some coding style guidelines (probably to be hosted on this wiki). Which would define the manner that code is written for the project. It would cover things like indentation style, tab widths, naming conventions... The general idea is to keep the code readable, manageable, and maintainable for all contributors. This document would possibly look similar to the style guidelines I previously wrote for the EnHacklopedia project [http://doc.kodewerx.net/guidelines.html].
+I would then devise some coding style guidelines (probably to be hosted on this wiki). Which would define the manner that code is written for the project. It would cover things like indentation style, tab widths, naming conventions... The general idea is to keep the code readable, manageable, and maintainable for all contributors. This document would possibly look similar to the style guidelines I previously wrote for the EnHacklopedia project [http://doc.kodewerx.org/guidelines.html].
 Also of importance would be developer- (and eventually user-) documentation. This could also live on the wiki, and would be easy for others to contribute to.
-Next I would provide bug tracking software for users and developers to file bug reports, feature/enhancement requests, and a means for developers to track the status of their own points of focus on the project. I've decided on [http://www.bugzilla.org Bugzilla] to track the project.
+Next I would provide bug tracking software for users and developers to file bug reports, feature/enhancement requests, and a means for developers to track the status of their own points of focus on the project. I've decided on [http://trac.edgewall.org Trac] to track the project.
 Finally, it would be a matter of hacking away at the project and making an initial commit to the version control repository. From there, provide a few core developers with commit access and watch the project begin to evolve into a tangible and proven debugger interface.

@@ Line 398: / Line 398: @@
 * '''Protocol''' - Describes a specific interpretation for data transmitted over a communications link.
 * '''Realtime Debugger''' - A high-level debugger which either itself runs a target, or watches the target run from outside of its own context. The realtime debugger typically has full control over its target, including the data and code of the target itself, as well as when and how the target is run.
 * '''Remote Debugger''' - A target-specific set of low-level and high-level debuggers with each debugger living on different target and host machines.
 * '''Standard''' - A formal technical description, usually written by an independent and neutral group or organization, with the intention of providing a set of mandatory and optional "rules" to be used for the purpose of compatibility. When used by the vast majority, a standard becomes a De-Facto standard.

@@ Line 411: / Line 411: @@
 ==See also==
-* [[Universal Debugger Protocol]]
+* [[Scalable Remote Debugger Protocol]]
 * [[Debugging Modern Computer Architectures]]
 [[Category:Developer_Documentation]]

← Older revision		Revision as of 03:20, 3 February 2009
Line 413:		Line 413:
	* [[Universal Debugger Protocol]]		* [[Universal Debugger Protocol]]
	* [[Debugging Modern Computer Architectures]]		* [[Debugging Modern Computer Architectures]]
		+
		+	[[Category:Developer_Documentation]]

@@ Line 358: / Line 358: @@
 One (of many) of the goals of this document is to gather resources and information from community members who may hold a valuable interest in the Universal Debugger Project's goals. One such resource is the collective brainpower of today's debugger developers. The immediate use of this collective brainpower would be for laying down the groundwork for the series of standards that the rest of the project will comply with and further be based upon. I want this collective brainpower to be assembled as a standards body independently and neutrally of the main project (and its implementation) in order to provide a constructive neutral territory where the standards body may collaborate without prior reservations or bias.
-In preparation for this project, I believe it is essential that a group of volunteers or "elected" members of a standards body assemble to define the series of standards necessary to make modular debugging and interoperability possible. This should be considered a top priority considering the success of universal debugging depends on it entirely. However, the programming work on a universal debugger interface can be done in parallel to, or entirely without, a standards body working out the finder details.
+In preparation for this project, I believe it is essential that a group of volunteers or "elected" members of a standards body assemble to define the series of standards necessary to make modular debugging and interoperability possible. This should be considered a top priority considering the success of universal debugging depends on it entirely. However, the programming work on a universal debugger interface can be done in parallel to, or entirely without, a standards body working out the finer details.
 Apart from the documentation guidelines and definition of acceptable open standards in debugging, preparation for this project also has dependencies on the base platform we will be working with. The Mozilla platform, [http://developer.mozilla.org/en/XULRunner XULRunner], has been chosen as the base for the project's debugger interface. Several potent references exist for the Mozilla platform, including a complete online book [http://books.mozdev.org/chapters/index.html]. Developers interested in the project's implementation should familiarize themselves with these and other resources.
@@ Line 366: / Line 366: @@
 CSS, XUL, and XBL (the latter two being dialects of XML) are useful for building user interfaces on the Mozilla platform. Javascript handles functionality on the user interface elements, and handles data to/from XPCOM. XPCOM is a means to allow Javascript to communicate with (and directly run) functions compiled in C++. Finally, CSS, XHTML, and Javascript are useful for user interface elements rendered with Gecko.
-A particularly good example of using XHTML in a Gecko browser widget is with a disassembler: assembly syntax can be highlighted and styled with CSS, subroutines can be contracted and expanded (code folding) with CSS and Javascript. And the entire document can be parsed as an XML document to re-assemble the code at a later time, or to export it to a txt file. Anchors (links) to subroutines and text strings (cross-references) can be clicked on to instantly jump to the relevant code. The browser can be put into "editing mode" to add comments, change instructions, and define new subroutines. Code flow analysis can be visually shown as Bezier curves and arrows drawn within a canvas element to the left of the instructions. And as with any [X]HTML document, the CSS can be changed to fit the user's tastes.
+A particularly good example of using XHTML in a Gecko browser widget is with a disassembler: assembly syntax can be highlighted and styled with CSS, subroutines can be contracted and expanded (code folding) with CSS and Javascript. And the entire document can be parsed as an XML document to re-assemble the code at a later time, or to export it to a txt file. Anchors (links) to subroutines and text strings (cross-references) can be clicked on to instantly jump to the relevant code. The browser can be put into "editing mode" to add comments, change instructions, and define new subroutines. Code flow analysis can be visually shown as Bezier curves with arrows pointing to the relevant instructions, drawn within a canvas element. And as with any [X]HTML document, the CSS can be changed to fit the user's tastes.
-This use of the Gecko layout engine provides some unique advantages: First, it makes the disassembler super-portable; no need to rewrite platform-specific custom controls that do difficult text layout and line drawing code, not to mention making it all editable. Second, it provides the perfect means to be styled by the user (CSS) any way she likes, and it will always look the same, no matter which operating system it runs on (with the exception of, perhaps, which fonts are installed and which are used by the CSS). Finally, it provides dynamic control over the content via Javascript and DOM manipulation, once again in a completely platform-independent way. With Gecko, you can do better things in your user interface, faster.
+This use of the Gecko layout engine provides some unique advantages: First, it makes the disassembler super-portable; no need to rewrite platform-specific custom controls that do difficult text layout and line drawing code, not to mention making it all editable. Second, it provides the perfect means to be styled by the user (CSS) any way she likes, and it will always look the same, no matter which operating system it runs on (with the exception of, perhaps, which fonts are installed and which are used by the CSS). Finally, it provides dynamic control over the content via Javascript and DOM manipulation, once again in a completely platform-independent way.
-The finally element of preparation is defining the naming conventions. It would be unwise to stick to "Universal Debugger Project" and "Universal Debugger Protocol" because as Lazy|Bastard of [http://www.gshi.org GSHI] publicly points out, the acronym UDP is already synonymous with the popular [http://en.wikipedia.org/wiki/User_Datagram_Protocol User Datagram Protocol]. He goes on to suggest a surrogate for the term "universal" (which is inaccurate at best; think "universal remote") with the more appropriate term "versatile". The naming of the project and protocol should be independent and chosen by their respective core contributors.
+The final element of preparation is defining the naming conventions. It would be unwise to stick to "Universal Debugger Project" and "Universal Debugger Protocol" because as Lazy|Bastard of [http://www.gshi.org GSHI] publicly points out, the acronym UDP is already synonymous with the popular [http://en.wikipedia.org/wiki/User_Datagram_Protocol User Datagram Protocol]. He goes on to suggest a surrogate for the term "universal" (which is inaccurate at best; think "universal remote") with the more appropriate term "versatile". The naming of the project and protocol should be independent and chosen by their respective core contributors.
 The project and protocol will each have a healthy start without settling on a name early on, but I might recommend that, at the very least, temporary code-names are chosen so that they may be referred to during the early development stages. I have no reservation on code-names, so any suggestions would be appreciated. As a final word on project naming, I realize that brands are important. Having an easily recognizable and understandable name will become a priority as the project starts coming into fruition.

@@ Line 302: / Line 302: @@
 How would this work? Well, one user, Hacker Sue, would begin a debugging session by connecting to her target over the standard communications layer, and she would then host the session as a server over plain old TCP/IP. She would invite other users to join her session in progress, and she would be notified when others attempt to make a connection. For reasons of practical security, these connections should be authenticated and encrypted with SSL or similar. She may choose to allow a connection from Hacker Joe only once, or she may agree to "remember" his public key/encryption certificate. Perhaps even more importantly, she may choose to reject all connection requests from Hacker Joe.
-Now that Hacker Joe has successfully connected and authenticated with Hacker Sue's debugging sessions, they set to work. The debugger interface contains a chat pane during hosted sessions, so they are able to talk about what they are seeing and doing. The interface also has "user markers" displayed within its content windows, like the disassembler and the memory editor. These user markers would provide a visual indication of what each user is currently looking at in the target. They could also provide a quick method to "jump" the view to the other users' view ports, and could even be "pinned" or made static; a way to automatically follow someone's view port as they move around in the code.
+Now that Hacker Joe has successfully connected and authenticated with Hacker Sue's debugging session, they set to work. The debugger interface contains a chat pane during hosted sessions, so they are able to talk about what they are seeing and doing. The interface also has "user markers" displayed within its content windows, like the disassembler and the memory editor. These user markers would provide a visual indication of what each user is currently looking at in the target. They could also provide a quick method to "jump" the view to the other users' view ports, and could even be "pinned" or made static; a way to automatically follow someone's view port as they move around in the code.
 Hacker Sue and Hacker Joe can now both control the target, stepping through code and watching how it works. They can also change data in memory and instructions within the CPU's code flow path. Each change made will be highlighted in colors specific to each user. They can't undo each others' work through standard-undo commands, but they can patch it just like any other data.

@@ Line 294: / Line 294: @@
 <blockquote>"Given enough eyes, all bugs are shallow."</blockquote>
-The first is a direct reference to multiple users working on debugging the same item, in parallel. The latter quote is slightly on the opposite; it means that you can have multiple users covering more ground by looking at different pieces of the code being debugged, and viewed from their own personal perspective on the problem. These are both great ideas to employ for large or difficult problems that many projects will face. The only problem is, it's usually handled with an "every man for himself" mentality. Multiple people running their own copies of the target, being debugged with their own debuggers, keeping their own notes, and withing and testing their own patches. All in solemn solitude.
+The first is a direct reference to multiple users working on debugging the same item, in parallel. The latter quote is slightly on the opposite; it means that you can have multiple users covering more ground by looking at different pieces of the code being debugged, and viewed from their own personal perspective on the problem. These are both great ideas to employ for large or difficult problems that many projects will face. The only problem is, it's usually handled with an "every man for himself" mentality. Multiple people running their own copies of the target, being debugged with their own debuggers, keeping their own notes, and writing and testing their own patches. All in solemn solitude.
 Why not take these two ideas one more step to the extreme? We can have several eyes on the same code, so let's also put several eyes on the same debugging session. Let's parallelize the debugging process with several minds double-checking each others work in real time, as they work; providing ideas and suggestions, and introducing patches directly into the stream for immediate testing.

@@ Line 276: / Line 276: @@
 * The debugger interface records its target's activity using simple standard protocol features such as single stepping, and reading register and memory states. When the user pauses the target, the interface has collected enough information to step ''backwards'' in architecture time. Essentially, a runtime undo feature.
-* The communications layer, being very generic, does not need to know the specifics of how the interfaces uses the data it is transmitting. A very simple example is that the user might be able to use the interface for capturing audio and video samples from a game running on the target architecture, simply by recording the state of the frame and audio buffers (using simple memory reads supported by the protocol) at a specified interval.
+* The communications layer, being very generic, does not need to know the specifics of how the interface uses the data it is transmitting. A very simple example is that the user might be able to use the interface for capturing audio and video samples from a game running on the target architecture, simply by recording the state of the frame and audio buffers (using simple memory reads supported by the protocol) at a specified interval.
 * The debugger interface allows incoming connections from other users to the debugging session in progress. There is a chat pane where connected users can talk about what they are doing, and they can watch each other scroll through the disassembler listing and making changes to instructions and assembler comments in real time. This "collaborative debugging" feature will be expanded upon in the next section.