JP2000215080A - Terminal device, repeating device, server and debugging information acquisition system, debug information acquiring method, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a terminal device, a repeating device, server and debug information acquisition system, debug information acquiring method, and recording medium which can obtain desired symbol information remotely without paying attention to differences of a target debug machine. SOLUTION: When a client C specifies a desired system, the specified system is connected to a system-adaptive server SS accessible to the debug information of the desired system through a virtual server VS and at a symbol conversion request for a program to be debugged, symbol information is sent from the system-adaptive server SS to the client C.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a terminal device, a relay device, a server, a debug information acquisition system, a debug information acquisition method, and a recording medium suitable for use in acquiring symbolic information and performing a debugging operation.

[0002]

2. Description of the Related Art In general, when verifying a developed source program, a method of compiling the source program with a compiler, converting the source code into object code, and executing the object code by a debugger to confirm whether the source program operates as designed. Is adopted. This debugger has
There is a symbolic debugger that can debug a program written in a high-level language such as C or C ++ at a source program level. This symbolic debugger uses information (symbol information table) and stack frames generated and output by the high-level language compiler based on the program to be debugged, and allows the user to refer to and change memory contents, trace program operations, and break Point setting, variable value setting, and variable value display can be performed at the level of a high-level language, and the operating status of the program to be debugged can be checked at any time.

Particularly in the development of large-scale software running under a variety of processors, such as a control program for a telephone exchange, such symbolic debugging requires a plurality of processors in order to obtain different debug information for each processor. This is performed between the remote server and a plurality of terminals. FIG. 16 shows such remote servers RS1, RS
2 schematically shows a configuration of a debugging system including a RS 3 and a user terminal T. In this case, each of the servers RS1 to RS3 holds debug information for the system α, debug information for the system β, and debug information for the system γ, and a user operating each terminal acquires symbol information of a desired system. Then, debugging work is performed.

[0004]

However, in such a conventional debugging system, debugging is performed for each debugging machine of the target system (in the example shown in FIG. 16, for each debugging machine of the systems α, β, and γ). It was necessary to align both the information and the program using the debug information. That is, in the conventional debugging method, it is necessary to individually create debuggers such as a debugger for the system α, a debugger for the system β, and so on. Therefore, when the types of target machines increase, it is necessary to provide both debug information on the target machine and a program for using the debug information.

[0005] Further, at the time of actual debugging work, it is necessary to remotely log in to a machine having desired debugging information. Therefore, it is necessary for the user to recognize in advance the address (for example, IP address) and host name of the target machine, the location of the debug information file and the location of the program using the debug information (path name and file name in the disk). there were. Then, in order to attempt a debugging operation on another target machine, there was a situation in which the user had to be aware of the machine to be changed. Furthermore, it has been pointed out that if a plurality of users concentrate on debugging work on a specific machine, the load on the host machine increases and debugging efficiency deteriorates.

Therefore, the present invention has been made in view of such a conventional problem, and obtains desired symbolic information from a remote terminal without being aware of a difference between target debug machines. It is an object of the present invention to provide a terminal device, a relay device, a server, and a debug information acquisition system, a debug information acquisition method, and a recording medium that can perform the operation.

[0007]

In order to achieve the above object, a terminal device according to a first aspect of the present invention is capable of accessing debug information of one or more systems out of debug information of a plurality of different systems. A terminal device that is connected to a plurality of servers via a relay device and obtains debug information of a desired system from among the debug information and debugs a program, and transmits a signal to request a line connection. Means for transmitting to the relay device, and after receiving a signal indicating approval of connection of the line transmitted from the relay device in response to the line connection request signal, a desired system from among the plurality of systems. Means for designating and notifying the relay device, and a server capable of accessing the debug information of the designated system, connected to the server via the relay device, And means for issuing a symbol conversion request for debug target program towards, is characterized in that it comprises a means for receiving a debug information transmitted from the server in response to the symbol conversion request.

A relay device according to a second aspect of the present invention is interposed between a terminal device and a plurality of servers each of which can access debug information of one or more systems out of debug information of a plurality of different systems. A relay device for connecting the terminal device and the server, a means for notifying the terminal device whether or not line connection is possible in response to a line connection request from the terminal device; and A means for receiving a notification about the system, a server capable of accessing the debug information of the specified system is selected from the plurality of servers to determine whether connection to the server is possible, and connection to the server is determined. Means for connecting the server and the terminal device when it is determined that the server is possible.

A server according to a third aspect of the present invention is connected to a terminal device via a relay device, and is capable of accessing debug information of one or more systems, the debug information comprising a number of components indicating symbol information. A server, in response to a request for symbol conversion for a program to be debugged issued from the terminal device, extracting means for extracting components necessary for performing the symbol conversion from the debug information, And transmitting means for generating symbol information using the extracted components and transmitting the generated symbol information to the terminal device.

A server according to a fourth aspect of the present invention is the server according to the third aspect of the present invention, further comprising: means for receiving a symbol conversion request issued from the terminal device via a predetermined interface; The generated symbol information is transmitted to the terminal device via the terminal device.

A server according to a fifth aspect of the present invention is the server according to the third or fourth aspect.
In the server according to the present invention, when it is not possible to create symbol information according to the symbol conversion request from the terminal device, the data storing a predetermined value is transmitted to the terminal device. Is what you do.

[0012] A debug information acquisition system according to a sixth aspect of the present invention comprises:
The terminal device of the first invention, the relay device of the second invention, and the server of any of the third to fifth inventions are provided.

According to a seventh aspect of the present invention, there is provided a debug information acquisition method, wherein, among the debug information of a plurality of different systems, one of a plurality of servers each capable of accessing the debug information of one or more systems and the terminal device are connected to the relay device And a debug information obtaining method for obtaining debug information of a desired system from the debug information on the terminal device side, wherein a signal to request a line connection is transmitted from the terminal device to the relay device. Transmitting the line connection request signal to the terminal device, the terminal device having received the signal indicating approval of the line connection transmitted from the relay device in response to the line connection request signal. Notifying the relay device by designating, and the server and the relay device capable of accessing the debug information of the specified system, and After the terminal device is connected, a process of issuing a symbol conversion request for the program to be debugged from the terminal device to the server, and debugging information transmitted from the server in response to the symbol conversion request to the terminal. Receiving on the device side.

The recording medium according to an eighth aspect of the present invention is characterized by recording a program for executing the method according to the seventh aspect of the present invention. The present invention is also practiced by storing and distributing this program on a recording medium such as a CD-ROM, a tape medium, and a DVD-RAM (including an act of distributing and downloading this program via a network). be able to.

[0015]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below in detail with reference to the accompanying drawings.

1. Configuration of embodiment 1.1. 1. Basic Configuration FIG. 1 shows an outline of a debugging system according to the present embodiment, and FIG. 2 shows a more specific configuration of the debugging system. This debugging system includes n clients C1 to Cn (denoted as "client C" when indicating an arbitrary client) which are debugging terminals, a virtual server VS, and a monitoring server WS. Server machine SM
And a system-compatible server SS having debug information unique to different CPUs (α, β, γ,...).
.alpha., SS.beta., SS.gamma.,... (in the case of indicating any system-compatible server among these system-compatible servers, the system-compatible server is referred to as "system-compatible server SS"). Are interconnected by an Ethernet ENET serving as a transmission path.

1.2. Configuration of Client and Server Machine The client C is a terminal device for a user to perform debugging work. The client C calls a source program stored in the storage device of the system compatible server SS to give a debug command, and acquires symbol-converted debug information (symbolic information) from the system compatible server SS. Then, the source program is verified with reference to the debug information.

At this time, when a signal indicating that it is desired to obtain debug information of a desired system is transmitted from the client C side, a system compatible server SS which can access the debug information of the desired system via the virtual server VS is connected to the server C. Connected automatically. For this purpose, the client C uses the library AL which functions as an access interface to the virtual server VS and the system compatible server SS.
Have. And this system compatible server SS
A request for debug information and a response to the request are made between the client and the client C, and debug information is supplied. Then, when a series of debug information is supplied, the client C becomes the system compatible server S
Issues a line disconnection request signal to S. On the other hand, the system-compatible server SS stores a log summarizing the work content requested from the client side in the virtual server VS,
A signal is sent to the virtual server VS to request log storage.

The virtual server VS accepts a connection request from the client C, and acts on a daemon process (for example, an inetd process on UNIX) of the system compatible server SS to connect the client C to the system compatible server SS. Is generated, and communication with each system-compatible server is performed. Then, after the client C and the system compatible server SS are connected and the debug information is supplied to the client C, a line disconnection request from the client C is accepted, and a message signal to that effect is transmitted to the system compatible server SS. Disconnect. Thus, the virtual server VS has a function as a relay device.

The monitoring server WS monitors the process of each system corresponding server SS and notifies the virtual server VS of the monitoring result as needed. In response to this, the virtual server VS sends the system-compatible server SS so that the load of the system is balanced.
And the connection between the client C and the system-compatible server SS is performed. Further, the monitoring server WS also monitors the process of the virtual server VS. If an abnormality is found in the process of the virtual server VS, the monitoring server WS restarts the process and executes all the connection processes connected to the virtual server VS. It is supposed to be rebuilt.

1.3. Configuration of System-Compatible Server As a system-compatible server SS, as shown in FIG.
System α that can access debug information for system α
There is a type that can access only one type of debug information, such as a server SSα for system and a server SSβ for system β that can access debug information for system β. Also, as shown in FIG. 2, one of a plurality of types of debug information can be accessed, such as a system γθ server SSγθ that can access either the system γ debug information or the system θ debug information. There are also types. These types of servers are appropriately distributed and arranged. In addition, a daemon process has been activated to enable external connections via the network.

This system compatible server SS has a huge number of exchange programs. That is, an enormous number of files including the source program, the object module, and the execution module are stored in the storage device (the details of these files will be described later). Then, it receives a symbol conversion request signal from the client C and performs symbol conversion processing, and as a result, transmits symbol information to the client C.

Further, upon receiving the debug information acquisition request from the client C, the system compatible server SS receives an ELF (Executable and Linkable For
mat) / DWARF (Debug With Arbitrary Record Forma
It is assumed that the component corresponding to t) has been accessed, and internally, an information element corresponding to a file format other than ELF / DWARF is accessed, and symbol information is extracted and converted to ELF / DWARF format. Return the result to client C.

1.3.1. File Formats and Debug Formats Handled by System-Compatible Servers The system-compatible server SS holds a large series of files related to switching programs, including source files and executable files, as described above, and is specified by the user. Supply debug information to the client as debug results for the program. Therefore, the format of the file and the debug information will be described.

The file format defines the configuration of an executable file defined for the OS to execute a program. Also, the debug format is
A compiler defines a set of information that generates correspondence between elements (source definitions and assigned addresses, etc.) between source files and executable files, and is mainly used when a debugger performs source-level debugging .
The file format and the debug format are used in pairs in the configuration of the program.

FIG. 8 shows the relationship between the file format and the debug format. As shown in FIG. 1A, an executable file 3 conforming to a file format is generated by compiling a source file 1 with a compiler 2. On the other hand, when an instruction to generate debug information is given at the time of compiling, debug information 4 conforming to the debug format is added as a part of the executable file 3 (this is called a session).

As shown in FIG. 2B, the correspondence between the file format and the debug format is determined by the CPU.
Each is different. That is, the CPU α
On platforms equipped with, SYSFOF is used for both the file format and the debug format. On a platform equipped with CPUβ, ELF is used as a file format and EWS is used as a debug format. On a platform equipped with CPUγ, ELF is used as a file format.
F, DWARF is used as a debug format.

FIG. 5 shows the functional configuration of the system-compatible symbolic server SS for using these various formats. As described above, the system-compatible symbolic server SS responds to the debug information acquisition request from the client C, and the CPU individual OS
The file format access module FAM and the debug format access module DAM are accessed via one of the α, CPU β OS individual unit Eβ and the CPU γ OS individual unit Eγ to acquire necessary information and supply it to the client side.

That is, from the client C side, the CPU α
When a request for acquiring debug information for the OS for OS is issued, the system corresponding server SS sends the OS
By operating α, the file format access module FAM and the debug format access module DAM both access the data in the SYSROF format.

Similarly, when the client C issues a debug information acquisition request to the CPU β OS,
The system corresponding server SS operates the OS individual unit Eβ for CPUβ to access the data in the ELF format as the file format access module FAM and the data in the EWS format as the debug format access module DAM.

Further, when the client C issues a request for obtaining debug information to the CPUγ OS,
The system compatible server SS operates the OS individual unit Eγ for CPUγ to access the data in the ELF format as the file format access module FAM and the data in the DWARF format as the debug format access module DAM.

Then, the system-compatible server SS extracts data necessary for performing symbol conversion from the data thus accessed, and creates symbol information.
Supply to the client C side.

2. Operation of Embodiment 2.1. Basic Operation Sequence FIG. 3 shows a basic operation sequence in such a debugging system. First, when a debug start command is given from the user of the client C, a signal (initial connection request signal) requesting connection of a line is sent from the client C to the virtual server VS (S1). The virtual server VS is a server SS corresponding to each system.
Determine the number of users connected to and the status of the process,
A signal to approve the line connection is sent to the client C (S2).

Next, the system name (α, β, γ,...) To be debugged is designated by the client C (S
3). In response to this, the virtual server VS sets the system corresponding server SS having the debug information of the designated system.
A check is performed to determine whether or not is activated (S4). Server SS holding debug information of the specified system
Is confirmed (S5), the name of the system compatible server SS and the communication port are designated together with a message signal to that effect (S6).

When a signal requesting symbol conversion for the program to be debugged is sent from the client C (S7), the system compatible server SS receiving this signal is sent.
Returns symbol information to the client C (S
8). Then, log information relating to a series of operations in steps S7 and S8 is stocked in the virtual server VS (S9). In the process of debugging the source program, the operations of steps S7 to S9 are repeatedly performed,
A series of debug information is supplied to the client C.

When the debugging information desired by the user is obtained, the client C issues a line disconnection request (S10). When the line disconnection request is approved by the system corresponding server SS (S11), a series of debug information acquisition sequence ends. The log information for these operation sequences is stocked in the virtual server VS (S12).

2.2. Operation Sequence Focusing on User-Side Operation Next, an operation sequence focusing on the user-side operation during a debugging operation will be described with reference to FIG. In the figure, the operation on the user side in the operation screen of the source level debugger on the client C side, the virtual server VS, the symbolic corresponding server SSα for the system α, and the source level debugger execution unit are handled and compiled with the system α as the target. FIG. 7 is a sequence diagram showing exchanges between the load modules LMα for the system α.

First, a signal for reserving the use of the symbolic server SSα is sent from the client C side (S20). In response, the virtual server VS newly starts a line connection process of the symbolic server SSα and gives an instruction to connect a line (S2).
1). Then, the virtual server VS returns the connection information of the symbolic server SSα based on the status from the network (S22), and the client C and the symbolic-compatible server SSα are connected. In this way, once the client C is connected to the symbolic server SSα, which is the target debug machine, in the subsequent operation, signals and data are directly exchanged between the two without passing through the virtual server VS.

Next, a signal is sent from the client C to request acquisition of a list of a large number of files (referred to as configuration files) stored on the disk in the symbolic server SSα and containing debug information (S23). When a list of configuration files is obtained, the user of the client C opens a desired source file from among the configuration files (S24) and sets a breakpoint (S25).

Then, a line number address conversion command for acquiring an address of a machine language executable by the microprocessor from the line number of the source file is issued to the symbolic server SSα for system α (S2).
6). The symbolic server SSα extracts the line number address conversion information from the load module LMα, and returns the address information to the client C (S27). The mechanism of the "line number address conversion" will be described later.

Subsequently, information on the break point set by the user is set for the load module LMα, and an instruction is given to execute from the beginning of the program to the break point (S29). Then, when the program is executed up to the break point, the control is returned to the debugger to stop the execution of the program, and the client C is notified of this (S30). As described above, the method of executing the program normally and transferring control to the debugger when the breakpoint is reached is as follows.
By replacing the machine language at the address specified by the breakpoint with an undefined instruction called an illegal function (IF) and executing this IF, a CPUHalt is generated, control is transferred to the debugger, and the IF is written back to the original instruction. 1 step and write the IF.

Further, the user refers to the variables in the source program on the debugger operation screen (S31) and gives a variable address conversion command to the system α server SSα (S31).
32). The system α server SSα extracts the variable address information from the load module LMα, and stores the address of the variable referenced in the source program in the client C.
(S33).

Next, the client C issues a command to the load module LMα so as to refer to the value of this variable (S34). Then, the value of this variable is returned from the load module LMα (S35).

Subsequently, the client C gives a command to trace and execute the program one step at a time on the operation screen of the source level debugger (S36).
Then, this command is transmitted to the load module LMα side, and the program is executed step by step (S3
7).

In addition, various operations for debugging are performed by the user from the debugger operation screen (S38), and a series of debugging operations on the client side is completed (S3).
9). Then, a signal indicating that the use of the symbolic server SSα is completed is transmitted to the virtual server VS (S4).
0), an instruction is given to the symbolic server to disconnect the line with the client C (S41). Finally, a notification is sent from the virtual server VS to the client C indicating that the line with the symbolic server SSα has been disconnected and the use has been completed (S42).

2.3. Operation Sequence in System-Compatible Server Next, the operation sequence in the system-compatible server SS will be described focusing on a mechanism for concealing a difference in the configuration of debug information that differs for each system.

The system compatible server SS stores information elements of various file formats and debug formats in an ELF file format, which is a common format, and in a D format.
An access is made using the information element of the WARF debug format, and debug information is supplied to the client side.

First, the dependency between the information elements in the ELF and DWARF will be described. FIG.
Shows the configuration of the ELF file format.
This ELF file format is an ELF header EL
1, the program header EL2, and the section SEC
1, section SEC2, ..., section SEC
, and a section header table EL in which information on these sections is aggregated.
4

FIG. 10 shows the dependence of these information elements on the ELF file format. This file format includes an EL that specifies the type of object file, the type of processor, and the like.
Stored are an F header EL1, a program header table EL2 in which information on segments in the executable file is recorded, a section name character string table EL3, and a section header table EL4. EL
5 to EL31 indicate files having various extensions as ELF file formats. The sections EL5 to EL31 are stored corresponding to the sections 1 to n,... Shown in FIG.

FIG. 11 shows the dependence of each information element in the DWARF file format. In this file format, unit information DW1, source file information DW2,... Exist in a form linked to the .debug section EL9, and various pieces of information are stored in a fragmented manner up to the inline function information DW35. , Symbolic debug information is provided (DW1 to DW35 are DWARF debug information, respectively). As described above, since the debug information is implemented as a part of the executable file, in order to access the debug information, it is necessary to work through the dependency sequentially from the top of the executable file.

Therefore, in the "line number address conversion" shown in step S26 of FIG. 4, the internal operation after the symbolic server SS receives the request from the client C differs for each corresponding CPU already described in FIG. The operation of the individual units will be mainly described.

2.3.1. Operation of the System Corresponding Server at Line Number Address Conversion FIG. 6 is a flowchart showing details of the line number address conversion. First, a command for line number address conversion is notified from the symbolic server SS to the symbolic server individual unit Eγ corresponding to the CPU γ (S50). The symbolic server individual unit Eγ receiving this command requests the ELF file format access unit (simply called a file format access unit) FA to acquire a debug section (S51). Then, the file format access unit FA checks the ELF header E in the ELF file.
L1 is acquired (S52).

Next, the file format access unit F
A performs an operation of extracting the section name character string table (S53). At this time, the file format access unit FA acquires the section name character string table EL3 from among the components of the ELF file (S54). Further, the ELF file format access unit FA gives a request for obtaining a debug section name to the DWARF debug format access unit (simply called a debug format access unit) DA (S55).

Subsequently, the file format access unit FA shifts to an operation of extracting a .debug section in the ELF file (S56). In this process, the file format access unit FA actually acquires the section header table EL14 (S57).

Next, the file format access unit F
A shifts to an operation of extracting a .debug section entry in the ELF file (S58). During this process, .d
An ebug section is obtained (S59).

Then, a request for acquiring unit information is issued from the symbolic server individual unit Eγ to the debug format access unit DA (S6).
0). In response to this, the debug format access unit DA acquires the unit information in the DWARF debug information (S61). Then, the debug format access unit DA extracts information elements recorded in the unit information (S62).

Subsequently, a request for acquiring an address corresponding to the line number from the symbolic server individual unit Er is issued to the debug format access unit (S
63). In response to this, the debug format access section DA acquires the source file information DW2 from the DWARF debug information, and obtains the source file information DW2.
The address corresponding to the line number is obtained by referring to the data in the area (S65).

As described above, the symbolic server accepts a symbol conversion request (“line number address conversion” in this example) from the user, and sends the request to the access unit DA of a file format that can be analyzed by itself and the debug format. Requests that are considered to be ELF / DWARF information elements (in this example, “get debug section”,
"Acquire unit information", "Acquire line number corresponding address")
, And performs an internal symbol information extraction process, converts it to a common format, ELF / DWARF format, and supplies it to the client C side. As described above, the system-compatible symbolic server SS has a function of concealing a difference in debug information different for each CPU.

2.3.2. Operation of the server corresponding to the system when a request for undefined information is issued Generally, since each file format / debug format has no correlation, information elements specified in one format are specified in another format. May not. Therefore, in order to absorb these inconsistencies, the symbolic server SS has a mechanism for returning a predetermined value without performing analysis when an access to an information element not specified in each format access unit occurs.

FIG. 7 shows the operation when information not defined in the file format and the debug format is accessed. First, the symbolic server SS inquires whether information corresponding to the request from the user side is defined in the file format and the debug format (S70). In response, the symbolic server individual unit E
Performs an inquiry process to the file format access unit (S71). Then, the file format access unit accesses the undefined information element corresponding to the file format A, and checks whether or not the element is the undefined information element (S72).

Subsequently, the symbolic server individual unit E
An inquiry process is performed to the debug format access unit (S73). In response to this, the debug format access unit accesses the undefined information element corresponding to the debug format A and checks whether or not the element is an undefined information element (S74). As described above, when access is made to information that is not defined in the file format and the debug format, a predetermined default value is returned to the client to cope with the access.

2.4. Operation at the time of acquiring the type name of the local variable Then, the operation at the time of actually acquiring the type name of the local variable i of the source program (file name test.c) in C language shown in FIG. 12 will be described with reference to FIGS. It will be described using FIG. FIG. 13 shows an operation when the system corresponding server SS accepts a debug information acquisition request from the client C.

First, the client C issues a request to resolve the type of the local variable i in the main function of the source program test.c (S80). In response, the system compatible server SS sends the debug information access section DA
Issue a request for obtaining unit information (source file information) (S81). Then, the unit information is returned from the debug information access unit DA (S82).

Next, the system corresponding server SS sets the PROC
A request for acquiring information (global function information) is issued to the debug information access unit DA (S83). In response to this, the PROC information is stored in the debug information access section DA.
Is returned to the system corresponding server SS (S84).
Further, in response to the request for acquiring the local variable information as the variable information, the local variable information is returned from the debug information access unit DA to the system corresponding server SS (S8).
5, S86). Thus, the notification that the type of the variable i is an integer type int is sent from the system corresponding server SS to the client C (S87).

2.4.1. Operation at the time of acquiring debug information in DWARF In such type solving processing of a source program, an operation sequence as shown in FIG. 14 is executed between debugger DG and debug information access unit DA. In the figure, the debug information access section DA is used for each of unit information (source file), PROC information (global function information), and variable information (local variable information).
The structure of the data returned from is specified in the sequence diagram.

Unit information, P, which is one element of debug information (symbol table) in these DWARFs
The detailed data structures of the ROC information and the variable information are shown in FIGS. In addition,
The positioning of these information elements in the DWARF data system is as described above (unit information DW1, global function information DW9, local function information DW14) shown in FIG.

As shown in FIG. 15A, the unit information includes, from the upper byte to the lower byte, a unit name (n + 1) byte, a language 4 bytes, a unit start address 4 bytes, and a unit end address 4 bytes , A row number information offset of 4 bytes, a compilation directory (n + 1) bytes, and an author name (n + 1) bytes arranged in the order of 3n + 19 bytes of data string DL1. Similarly, the PORC information and the variable information are each composed of data strings DL2 and DL3 arranged in the order of the attribute elements shown in the tables of FIGS. 15B and 15C.

The unit information acquisition request (S
In the processing of 81) and unit information return (S82), unit information including the data string DL1 is returned to the debugger DG from the debug information access unit DA. Therefore, on the debugger DG side, the upper (n +
1) The contents recorded in the byte are read, and a source file name of test.c is obtained.

Next, in the processing of the PROC information acquisition request (S83) and the return of the PROC information (S84), unit information including the data string DL2 is returned from the debug information access unit DA to the debugger DG. Therefore, the debugger DG reads the contents recorded in the upper (n + 1) bytes of the data string DL2, and acquires a global function name of main.

Further, in the processing of the variable information acquisition request (S85) and the return of the variable information (S86), the debug information access unit DA returns the unit information including the data string DL3 to the debugger DG. Therefore, the debugger DG reads the contents recorded in the upper (n + 1) bytes of the data string DL3, acquires the type name of the local variable named int, and acquires the symbolic information that “the type of the local variable i is int”. can do.

3. Advantages of Embodiment (1) Debugging work can be performed on a local terminal without remote login, and machine load distribution can be achieved since the virtual server is switched to a dedicated server for the target system. By this virtual server transfer function, the client can obtain symbolic information and perform debugging work only by recognizing only the virtual server without being aware of many servers. (2) From the viewpoint of debugging tools on the client side,
Even if the debug information differs to some extent, it is possible to access the debug information with the same interface,
There is no need to develop individual debugging tools for different debug information for each processor. (3) Further, by modularizing parts corresponding to various debug formats (individual parts on the system-compatible server side), the types of the corresponding debug formats can be increased at any time.

4. Modifications The present invention is not limited to the above embodiment, and various modifications are possible as follows, for example. (1) In the present embodiment, the C compiler or the C ++ compiler has been described as a compiler for generating debug information. However, by adding an individual access routine, other program languages (for example, J
ava, etc.). (2) In the present embodiment, an example is described in which one virtual server is used. However, when processing from a large number of clients is concentrated, a mirror server having a function as a virtual server is provided. It is also possible to appropriately distribute the processing to this mirror server.

[0073]

As described above in detail, according to the present invention, when debugging a program, symbol information can be acquired from a local terminal through a common interface without remote login.

[Brief description of the drawings]

FIG. 1 is a configuration diagram illustrating an outline of a debugging system according to an embodiment;

FIG. 2 shows a specific system configuration of the debugging system.

FIG. 3 shows an operation sequence between a client, a virtual server, and each system-compatible server.

FIG. 4 shows a flow of processing mainly on a user side when performing a debugging operation using the debugging system.

FIG. 5 illustrates a functional configuration of a system-compatible symbolic server.

FIG. 6 shows a sequence when row number address conversion is performed using ELF / DWARF.

FIG. 7 shows a mechanism for accessing an information element that is not defined in a file format or a debug format.

8A and 8B show a relationship between a file format and a debug format. FIG. 8A shows both relationships from the viewpoint of a debugging work, and FIG. 8B shows a specific relationship between each format. Things.

FIG. 9 shows a configuration of an ELF file format.

FIG. 10 illustrates a dependency relationship between information elements in the ELF file format.

FIG. 11 illustrates a dependency relationship between information elements in the DWARF debug format.

FIG. 12 shows an example of a source program, particularly showing local variables described in the source program.

FIG. 13 shows an example of a sequence from when a debug information acquisition request is issued from a client to a system corresponding server to when debug information is actually returned.

FIG. 14 shows a situation when symbolic information is acquired in DWARF.

15A and 15B show the configuration of a symbol table in DWARF, where FIG. 15A shows unit information, FIG. 15B shows global function information, and FIG. 15C shows local variable information.

FIG. 16 shows a configuration of a conventional remote debugging system.

[Explanation of symbols]

1 Source File 2 Compiler 3 Executable File 4 Debug Information VS Virtual Server WS Monitoring Server SM Server Machine AL Access Library ENET Ethernet (registered trademark) FA File Format Access Unit DA Debug Format Access Unit SS (Sα, Sβ, Sγ, ...) System compatible (symbolic) server C (C1, C2, C3, ...) Client E (Eα, Eβ, Eγ, ...) Individual part LM (LMα, LMβ, LMγ, ...) for each processor・) Load module EL1 to EL31 ELF file format component DW1 to DW35 DWARF file format component

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Yoichi Yamada 1-9-1, Konan, Minato-ku, Tokyo NTT Communicationware Co., Ltd. (72) Inventor Masaaki Shinjin Minato-ku, Tokyo 1-9-1 Konan NTT Communications Wear Co., Ltd. (72) Inventor Takeshi Tate 1-9-1 Konan, Minato-ku, Tokyo NTT Communications Wear Co., Ltd. F Terms (reference) 5B042 GA02 GA12 GC08 HH04 HH41 5B045 GG01 JJ49 5B085 AC09 BG07

Claims (8)

[Claims] 1. A debugger, which is connected via a relay device to a plurality of servers each of which can access debug information of one or more systems among debug information of a plurality of different systems, and outputs a desired one of the debug information. A terminal device for acquiring debugging information of a system and debugging a program, wherein the terminal device transmits a signal requesting connection of a line to the relay device, and the relay device responds to the line connection request signal. Means for designating a desired system from among the plurality of systems and notifying the relay device after receiving a signal indicating approval of the line connection transmitted from the device; and debugging information of the designated system. After connecting to a server accessible to the server via the relay device, a symbol conversion request for the program to be debugged is issued to the server. And a means for receiving debug information transmitted from the server in response to the symbol conversion request. 2. A terminal device and a plurality of servers, each of which is capable of accessing debug information of one or more systems among debug information of a plurality of different systems, are interposed between the terminal device and the terminal device, and A relay device for connecting to a server, a unit for notifying the terminal device whether or not line connection is possible in response to a line connection request from the terminal device, and a unit for receiving a notification regarding a designated system from the terminal device. And selecting a server that can access the debug information of the specified system from the plurality of servers, and determining whether or not connection to the server is possible, and determining that connection to the server is possible. Means for connecting the server and the terminal device in such a case. 3. Connected to a terminal device via a relay device,
A server which is capable of accessing debug information of one or more systems and which includes a large number of components suggesting symbol information, wherein a request for symbol conversion for a program to be debugged issued from the terminal device is provided. Extracting means for extracting a component necessary for performing the symbol conversion from the debug information, creating symbol information using the extracted component, and transmitting the symbol information to the terminal device. A server, comprising: a transmitting unit that transmits. 4. The server according to claim 3, further comprising: means for receiving a symbol conversion request issued from the terminal device via a predetermined interface, wherein the transmitting means comprises:
A server for transmitting the created symbol information to the terminal device. 5. The server according to claim 3, wherein when it is not possible to create symbol information according to the symbol conversion request from the terminal device, the server stores the data in which a predetermined value is stored. A server for transmitting to a terminal device. 6. The terminal device according to claim 1, and a terminal device according to claim 2.
A debug information acquisition system comprising: the relay device according to claim 1; and the server according to any one of claims 3 to 5. 7. A terminal device is connected via a relay device to any one of a plurality of servers each of which can access debug information of one or more systems out of debug information of a plurality of different systems, and A debug information acquisition method for acquiring debug information of a desired system from the information on the terminal device side, wherein a signal for requesting a line connection is transmitted from the terminal device to the relay device. The terminal device, which has received the signal indicating approval of the line connection transmitted from the relay device in response to the line connection request signal, designates a desired system from among the plurality of systems to the relay device. Notifying, and after connecting the terminal device via the relay device and a server capable of accessing the debug information of the designated system, Issuing a symbol conversion request for a program to be debugged from the device to the server, and receiving at the terminal device debug information transmitted from the server in response to the symbol conversion request. A method for acquiring debug information. 8. A recording medium on which a program for executing the method according to claim 7 is recorded.