Design and application of cross-platform PHP debugger--Exploration and design ____php

In the "Cross-platform PHP debugger Design and use Method-project", I identified the use of Xdebug as the debugger plug-in part of the basic components. Xdebug provides a remote debugging function (the relevant information can be described in the Https://xdebug.org/docs/remote), our project is based on this feature implementation. (reprint please indicate the CSDN blog for Breaksoftware)

Remote debugging is a kind of debugging method based on network transmission mode, then it must have two parts of server and client. Both the server and the client are relative, because a client may become a service after communicating with the servers, and the service end becomes a client after one communication. Xdebug is part of the server in this model because it is embedded inside the PHP actuator, affecting the PHP execution process, and these core functions must be part of the service side. It should also have the ability to receive and respond to requests.

Xdebug provides two ways to connect, one is a fixed address single line connection. One is the unknown address multi-line connection.

Let's take a look at the fixed address single line connection, the following diagram of its execution flow

Embedded in the PHP execution program xdebug A 80-port control Debugging IDE initiates an HTTP debug request Xdebug according to the Remote_host and Remote_ in the configuration item The Port field, which is the IP and IDE-open port of the IDE's machine, initiates a connection to the IDE and requests the IDE and the Xdebug to establish a connection, communicate Xdebug Answer 2 HTTP requests in the process there is a problem with configuring the IDE's IP in Xdebug and port so that only the IDE on one machine can communicate with the xdebug. In order to support multiple user simultaneous connections, Xdebug also provides a way to connect to unknown IP, let's look at the flowchart:
Xdebug embedded in the PHP execution program open a 80-port control Debugging IDE initiates an HTTP debug request Xdebug Configuration Items The traditional Chinese Medicine configuration remote_connect_back is 1 or on, and the Remote_port is also configured. xdebug resolves the IP of the remote IDE according to the request in 2, and then initiates a connection through the IP and Remote_port, which connects the IDE and Xdebug, and communicates xdebug the HTTP request in the 2 process. How do we choose to respond to both of these ways? First, let's look at a question, if you have a friend who has a connection to NetBeans and Xdebug, you'll remember to configure the code FTP address in NetBeans. Because as an IDE you need to be able to see the files that are being executed on the remote machine (because you want to show the user where the execution is, where to place the breakpoint, etc.). Although the source command for Xdebug can get the contents of the current execution file, for a debugger, we often need a lot of things that haven't happened yet.         Therefore, it is necessary for the IDE to have access to remote files. However, this step will also affect the user's progress in configuring the debugger. Because in order to debug, I also have to open an FTP service to the remote machine, but also to configure the service corresponding to the local address, these seem to have to do with the behavior of debugging. So in order to solve this problem, we simply do not release the function of editing source code in the debugger. At the same time, we put the IDE and Xdebug on the same machine so that the IDE can read local PHP-executed files so that you don't have to turn on the FTP service.         So, we choose the fixed IP single line connection way. It should be pointed out here that we must not write dead IP when we configure Remote_host. Because our code and configuration can be copied to other environments at any time, writing dead values will seriously affect their applicability, so we can use localhost instead of fixed IP

Xdebug.remote_enable=on Xdebug.remote_handler=dbgp Xdebug.remote_host=localhost xdebug.remote_port=9000

After the         Communication method is resolved, we need to pay attention to the communication protocol problem. Xdebug is using a protocol called DPGP, whose protocol documents are shown in https://xdebug.org/docs-dbgp.php.         This agreement document is relatively long, but it is fairly simple. As the initiator of the behavior request, you need to send command-a value-b value to Xdebug ... This type of request content, and Xdebug returns an XML content. The reason for this seemingly asymmetric request type is that XML content generation is easy to interpret, but parsing requires additional libraries. However, the authors obviously do not want to introduce these less important third-party libraries. In fact, I think this kind of request is very good, it is very much like we use other input debugger, such as WinDbg.         Next let's take a look at the process of debugging the IDE gets some of the properties supported by Xdebug (different versions of Xdebug support different features, so the IDE first needs to know what it supports and what it doesn't) IDE set some Xdebug properties , breakpoints, and so on, Xdebug let the code run until it encounters a breakpoint or runs to the end if a breakpoint is encountered, the IDE can ask Xdebug for some variable values, stack information, or modify some variable values         Let's look at a more similar process in the Xdebug document, which also shows how the whole debugging process looks like.

IDE:  feature_get supports_async DBG:  yes IDE:  stdin redirect DBG:  ok IDE:  stderr redirect DBG:  ok IDE:  run DBG:  stdin data ... DBG:  stdin data ... DBG:  reached breakpoint, done running IDE:  give me some variables DBG:  ok, here they are IDE:  evaluate This expression DBG:  stderr data ... DBG:  ok, done IDE:  run IDE:  break DBG:  ok, breaking DBG:  at Breakpoint, Done Running IDE:  stop DBG:  good bye

Although it seems like the whole protocol is simple, I'm not going to implement a set of libraries that send requests and parse the results of XML returns. I looked at the other software's Xdebug communications library basically called a set of Python implementation library called PYDBGP, I am also ready to use it.         Sometimes it is very necessary to stand on the shoulders of giants to achieve something. PYDBGD's official address is http://jaredforsyth.com/pydbgp/. We only need to take the bin in the download package and DBGP the files in the two directories. Because this piece of information is very small, so it also took me a certain amount of time to study the use of this set of library. And this set of library implementation also has a lot of flaws, I also always in non-stop exploration and play patch in the forward. Fortunately, after a period of hard work, finally it and xdebug through. Let me show you a PYDBGP and xdebug interaction process
The 1th part tells the IDE what the Ide-key is for debugging and which port to listen to. Because I'm debugging in NetBeans as a template, my ide-key is also the ide-key:netbeans-xdebug of NetBeans and xdebug interaction. Of course, this value can be changed to something else, but it's the same as the Idekey value of the Xdebug configuration file.

xdebug.idekey= "Netbeans-xdebug"

Then I started listening on the local 9000 port. This 9000-port number is also not set casually, but also the same as the Remote_port value in the Xdebug configuration file

        At this point we can launch a request in the Web page to trigger PHP execution. This trigger behavior is divided into two types, which I will introduce later. The         Web page is in a waiting state at this point, indicating that Xdebug has interrupted the execution of the PHP process. So we can do the next step.         We execute the sessions directive to see which connections are currently established. As shown above, PYDBGP returns the connection information. Of course, this presentation is not xdebug raw data-the original data is XML. After         knows the connection number, we use the Select command to enter a specific connection. Then use status to view the status of the debugging. After the first status is executed, the debugger is in the starting state, which is a state of interruption that has not yet entered the PHP code layer. We perform "Step Over"--step over the operation once, this time PHP execution will enter the code. Use the Stack_get directive to view the current call stack information, which includes the stack number, file path, and function name. If we don't care about the execution, call the Run command and let the program run to the end. The status command is invoked at this time to see the debugger in a stopping state. Run again at this time, this debugging is completely over. When we finish, we exit the current debugging using the Quit instruction. If there are other debugging requests coming in, you can then call sessions to view the connection number and repeat the debugging process described above. The 4 above is a manifestation of this process.         If you do not want to debug, you can call quit to exit the entire PYDBGP.         PYDBGP help us connect xdebug, forward commands, and parse the returned XML results. But it provides only the standard input mode of the request interface, we cannot call the API like the direct call to these interfaces. And I have no intention of changing this interface into an API form. So I decided to use parent-child process communication, the parent process is our business logic, the child process is PYDBGP, the parent-child process through the redirection of input and output to communicate. This was my initial idea, but the final redirect was also lost because Python has compatibility issues with this approach on different platforms (Windows and Linux). This is also to force me to use standard sockets to communicate in the later stage of the project, fortunately, I did better code coupling before, the alternative quicklyIt's used. Here feeling, some things want to always beautiful appearance, and reality is often twists and turns. Of course, with the increase in experience, imagination will be more and more reliable, this is the role of experience.
Xdebug provides us with a lot of basic functionality for debugging. But as a debugger, we should develop more combinatorial features on top of those foundations, which can help users find problems faster. So we also need to do some high order encapsulation of these features, which we'll introduce later. There are some features that may not be required by the debugger, such as log file monitoring, so this piece will also be some of our debugger's auxiliary functions. So the structure of our debugger is this