KR100334903B1 - Target server apparatus in remote development environments for embedded real - time software and controlling method thereof - Google Patents

Abstract

An object of the present invention is to provide a target server device and a control method thereof, which enable remote development of embedded real-time software using various development tools on a host.

According to the present invention, a target for driving the target server according to its characteristics by reflecting a flag set in advance, interpreting a function requested by a tool on the host system, and calling a service according to the target A server controller; A symbol table manager that manages information about a system symbol table of the target system and subroutines, variables, and module ids of all execution modules loaded in the target system according to a service called by the target server controller. Wow; An execution module manager configured to load / unload an executable file in the host system to a target system and to manage the loaded module list on the host system; Provided is a target server control device comprising a communication backend manager for allowing the target system to communicate with the tools on the host system when the target server is running.

Description

Target server apparatus in remote development environments for embedded real-time software and controlling method

The present invention relates to a target server device that enables remote development of embedded real-time software using various development tools on a host, and a control method thereof. In particular, an environment in which remote development can be performed using various tools on a host system The present invention relates to a target server device which performs a role of a tool intermediary for supporting all development activities through a window to access a target system, and a control method thereof.

The built-in system for information appliances is a small computer, but it's small compared to the personal computers we usually use. That's why it's very difficult to develop an application with a large resource-intensive software such as a debugger built into an embedded system. Thus, there have been attempts to develop applications for embedded systems in remote computers (hereinafter referred to as host systems) by connecting to target systems via serial or Ethernet.

In the past, developing applications with only one debugger, such as GDB (Gnu DeBugger), which has a debugger client on a host and a debugger server on a target, has been the development environment of most embedded software. In addition to the debugger, a variety of tools, such as remote shells and target resource monitors, have been raised on the host.

Embedded 32-bit microprocessors are inexpensive, and the advent of embedded microprocessors dedicated to specific applications is driving the demand for embedded real-time applications for information consumer products such as communication terminals and digital TVs. In addition, embedded applications are becoming more complex, such as processing large data such as multimedia, and the development environment for this is that the resources of the target system are very limited, so that the communication burden between the host system and the target system is increased. There is a problem that large.

In order to develop embedded software on a remote host system, in the past, a remote debugger such as GDB having a debugger client on a host system and a debugger server on a target system is used, but the embedded software is increasingly complicated. Therefore, the necessity of understanding the situation of the target system in real time is raised while the remote development environment is independent of the target system and using various development tools. To meet this need, he began to build an environment for developing embedded software by connecting to a target system with several tools on the host system.

1 is a connection structure diagram of a remote development tool and a target system of embedded software according to the prior art, which will be described in detail as follows.

As shown in FIG. 1, when there are several developer tools, two cases may be considered. When decorating a development environment using commercialization tools of different vendors (Vendor), the connection structure between the host system and the target system is as shown in 110 of FIG. However, in the structure 110 of FIG. 1, each tool is connected to the target system to access resources of the target system. In this case, when each tool is accessed at the same time, the communication load of the target system becomes very large. In addition, when an application developer using a tool causes a serious error in the target system, the developer using another tool cannot use the target system. Even with different tools, each tool must have duplicate data, such as a symbol table of a target system, and in some cases, consistency of duplicate data can be a problem. In addition, even when adding a new tool on the host system, there is a problem that it can be a big burden on the tool developer because it needs to know in detail about the communication method and the target system.

The prior patent 'Method of realizing process execution control service in cross debugging server' (Registration No .: 1997-069487), registered by Lee Eun Hyang and 2 others, is a method of realizing process execution control service in a cross debugging server operating on a target system. It is about.

A method of realizing a process execution control service in a cross debugging server provided by the above patent includes a first step of accepting a process execution control service request from a cross debugging client in a host system and determining what type of service request the service is. A third step of performing a corresponding service according to the type of process execution control service requested in the first step; and a third step of providing a result of performing the second step to a cross-debugging client in a host system. It is composed.

The cross-debugging server of a real-time operating system for providing the process execution control service includes one or more service daemons, a debugging server engine, and a remote communication processing unit. The service daemon receives the execution control service from the cross debugging client and controls the execution of the process such as stopping / resume any process in the user program using the debugging service engine, and sends the result to the cross debugging client through the remote communication processing unit. To communicate with When it receives a request to stop running a process, it finds the process, stores the current state of the process, and defines the state of the process when it resumes running.

If the process to be stopped is not waiting for any event, the process context switch stores the information needed in the process execution control block and excludes it from the process scheduling ready queue.

If the process is in a waiting state, the starting point of the system call that made the waiting state is searched through the process stack, the program counter is pointed to that starting point, and the stack pointer and frame pointer are placed at the beginning of the system call. Adjust to point to the corresponding stack frame. Finally, the input parameters used by the system call are found in the stack frame, reloaded into the parameter transfer register, and the rest is processed when the other state is not in the standby state. This makes it easy to control the execution of a process in debugging the running process by providing a process of suspending only the running process and resuming execution without causing the system to stop running. A series of processes can be shortened to present an efficient aspect.

However, this prior patent does not overcome the problems described above.

The present invention has been made to solve the above problems of the prior art, all the development activities through a single window to access the target system in an environment that can be remotely developed using a variety of tools in the host system company It is an object of the present invention to provide a target server apparatus and a control method thereof, which can be performed.

1 is a connection structure diagram of a remote development tool and a target system of embedded software according to the prior art,

2 is a structural diagram of a connection between a remote development tool and a target system of embedded software according to an embodiment of the present invention;

3 is a block diagram of a remote development system of embedded software according to an embodiment of the present invention,

4 is a structural diagram of a target server according to an embodiment of the present invention,

5 is a classification table according to the function of the tool interface protocol shown in FIG. 4;

6 is a flowchart illustrating a process in which a target server device operates as a service daemon to provide a service for a tool according to an embodiment of the present invention.

7 is a flowchart illustrating a process of receiving a service request from various development tools and target agents on a host while the target server device operates as a daemon according to an embodiment of the present invention.

8 is a flowchart illustrating a process of loading and executing embedded software cross-compiled in a host system using a target server device according to an embodiment of the present invention.

According to the present invention for achieving the above object, to enable the remote development of embedded real-time software running on the target system using a development tool on the host system (Host System) In the target server device, the target server is driven in accordance with the characteristics by reflecting a predetermined flag, and the function requested by the tool on the host system is interpreted to call a service according to the target server device. A target server controller for performing a giving function; A symbol table manager that manages information about a system symbol table of the target system and subroutines, variables, and module ids of all execution modules loaded in the target system according to a service called by the target server controller. Wow; An execution module manager configured to load / unload an executable file in the host system to a target system and to manage the loaded module list on the host system; Provided is a target server control device comprising a communication backend manager for allowing the target system to communicate with the tools on the host system when the target server is running.

In addition, in a target server control method for remotely developing embedded real-time software operating in a target system using a development tool on a host system, A first step of driving the target server according to a characteristic by reflecting a preset flag, interpreting a function requested by a tool on the host system, and calling a service corresponding thereto; According to the service called in the first step, the information on the system symbol table of the target system and the subroutines, variables, and module ids of all the execution modules loaded on the target system is managed to execute the executable file on the host system. After loading / unloading to the target system, a target server control method is provided, comprising a second step of managing the loaded module list on the host system.

In addition, a target server device that enables remote development of embedded real-time software operating in a target system using a development tool on a host system is provided on the host system. In the method of operating as a service daemon (Service Daemon) to service the tool, a target agent for inputting various configuration information for the target system, and performs the function of communicating with the target server of the host system A first step of selecting a communication method according to the communication method of the (Target Agent); After selecting the executable file format (OMF: Object Module Format) to be converted according to the configuration information input in the first step and the information input from the development tool on the host system, select an operating system file of the target system, A second step of making an operation start request of the target server; If there is a request to start operation in the second step, the target server and the target agent are connected, and necessary information is transmitted to the target server, and then the operating system executable file of the target system is read and the target system is read. And a third step of creating a symbol table and initializing the target server to drive the target server daemon.

In addition, by using a target server device, a method for remote development by loading cross-compiled embedded software on a host system to a target system, when the development tools on the host system request a service, Extracting information decipherable according to an executable file format and symbols related to the executable file; A second step of extracting segment information such as text and data related to the information and symbol extracted in the first step and loading embedded software; There is provided a remote development method of embedded software using a target server device, comprising a third step of performing an accuracy check by executing the embedded software loaded in the second step.

In addition, the target server (Target Server) and the target server to enable the remote development of the embedded real-time software running on the target system using the development tool on the host system (Host System) In order to communicate with the development tools, indicating the connection between the development tool on the host system and the target server, indicating a disconnected state, restarting the target server daemon and the target system, or checking the list of the target server. A session management area for inputting, modifying, viewing, and deleting the data; Target information that can be entered, modified, inquired, and deleted to execute an executable file loaded on the target system or to set a type of a target agent to be in communication with the real-time kernel of the embedded server and the target server of the host; A target operation area; A symbol management area capable of inputting, modifying, retrieving, and deleting the target system symbol information and a table of symbols related to executable files to be loaded; A memory-related area capable of inputting, modifying, viewing, and deleting a part of the memory of the target system as necessary to perform writing and reading; A context management and debugging area capable of inputting, modifying, viewing, and deleting to perform debugging functions while maintaining a context; Target server characterized in that it comprises an event management area that can be input, modified, inquired and deleted for event management that can be exchanged between the development tool on the host system, the target server device and the target agent. And a computer-readable recording medium having recorded thereon communication data with development tools on the host system.

In addition, a target server control program for executing remote development of embedded real-time software running on a target system using a development tool on a host system may be executed. In a computer-readable recording medium, the target server is driven in accordance with a predetermined flag, and a function requested by a tool on the host system is interpreted to invoke a service corresponding thereto. A first step of doing so; According to the service called in the first step, the information on the system symbol table of the target system and the subroutines, variables, and module ids of all the execution modules loaded on the target system is managed to execute the executable file on the host system. After loading / unloading to the target system, a computer-readable recording medium having recorded thereon a program capable of executing what is included is provided, including a second step of managing the loaded module list on the host system.

In addition, a target server device that enables remote development of embedded real-time software operating in a target system using a development tool on a host system is provided on the host system. A computer-readable recording medium having recorded thereon a program operating as a service daemon for servicing a tool, comprising: inputting various setting information about the target system and communicating with a target server of the host system A first step of selecting a communication method according to a communication method of a target agent that performs a function of managing a; After selecting the executable file format (OMF: Object Module Format) to be converted according to the configuration information input in the first step and the information input from the development tool on the host system, select an operating system file of the target system, A second step of making an operation start request of the target server; If there is a request to start operation in the second step, the target server and the target agent are connected, and necessary information is transmitted to the target server, and then the operating system executable file of the target system is read and the target system is read. There is provided a computer-readable recording medium having recorded thereon a program capable of executing a symbol table, including a third step of initializing the target server to drive a target server daemon.

A computer-readable recording medium having recorded thereon a program for remote development by loading embedded software cross-compiled on a host system using a target server device in a target system, the host system comprising: A first step of extracting information decipherable according to an executable file format and symbols related to the executable file when the development tools on the service request a service; A second step of extracting segment information such as text and data related to the information and symbol extracted in the first step and loading embedded software; There is provided a computer-readable recording medium having recorded thereon a program capable of executing the program comprising a third step of executing the embedded software loaded in the second step to perform an accuracy check.

In the following, with reference to the accompanying drawings, a preferred embodiment according to the present invention will be described in detail.

2 is a diagram illustrating a connection structure of a remote development tool and a target system of embedded software according to an embodiment of the present invention.

Unlike the remote development tool of the conventional embedded software, according to an embodiment of the present invention, the tool collects common elements such as functions and data necessary for connecting to the target system and performing a desired function. We have devised a structure that allows the intermediary to perform. That is, the target server device corresponds to the tool broker in 120 of FIG. 2. To support this structure, the target server acts as an intermediary between the tools on the host system and the target system. The benefit of adopting this structure is that by keeping only one channel in one target system, it can save the limited resources of the target system and define common interface functions that tools can access the target system. This makes it easier to add new tools to the current development environment.

In addition, the target server device maintains the target system information, which does not change like the target system symbol table, so that the target server device on the host can serve the information desired by the tool without having to communicate with the target.

3 is a block diagram of a remote development system of embedded software according to an embodiment of the present invention.

The environment to which the present invention is applied is a system capable of developing an application program to be mounted on a real-time operating system of an embedded processor in which the host system 210 and the target system 220 are connected in a serial or Ethernet manner. At 200. The host system 210 includes a host board 214, which is hardware, a host operating system 213 on which a development support tool can operate, 213 (designed by Windows NT in the present invention), and a target server most relevant to the present invention ( 212) and various development tools 211, such as a remote debugger, an interactive shell, and a resource monitor. The target system 220 may be embedded in a home appliance or a mobile terminal such as a digital television. The target system 220 includes a target board 225 corresponding to an embedded processor, a built-in real-time kernel 224, and a target server of the host system 210. There is a target agent 223 to communicate with 212 and a real-time application library 222 such as a graphic library, and the application program 221 to be developed thereon will be mounted thereon. After the development of the application to be mounted on the target system 220 through source level debugging, the target agent 223 plays its role.

In other words, the tools 211 on the host system, the target server 212 and the target agent 223 are required for application development to be mounted on the target system 220. The target server 212 is the main element to be addressed in the present invention and the tools 211 on the host system must go through the target server 212 in order to access the target system 220.

4 is a structural diagram of a target server according to an embodiment of the present invention, wherein the target server 300 includes a target server controller 310, a tool interface protocol 320, a communication backend manager 330, and a backend. The protocol 340, the symbol table manager 350, the execution module manager 360, and the target memory manager 370 are configured.

This will be described in detail as follows.

The target server controller 310 serves as a command center that manages everything that occurs inside the target server. The target server 300 is driven in accordance with its characteristics by reflecting a flag set by an application developer, and a function of interpreting a function requested by a tool on a host system and calling a service corresponding thereto is provided. In other words, it is a module that waits for the request of the tool by creating a target server service daemon by running the appropriate modules according to the communication method and execution module type used by the user of the tool.

The tool interface protocol 320 is to provide a common interface to the tools 211 on the host system to unify the target system and the connection window. The protocol includes a target server connection function, symbol processing function, execution time target system information providing function, event management function, execution module loading function, debugging support function, memory related function, target function call function and the like. By defining all the functions that can be requested by each function, one API (Application Program Interface) or several APIs can be used to realize the desired functions. When the APIs receive a request from the tools through communication, the target server controller 310 calls a service function for the corresponding API.

The symbol table manager 350 manages information about a system symbol table of a target system and subroutines, variables, and module ids of all execution modules loaded in the target system. It is possible through the symbol table manager 350 that the tools 211 on the host system, such as the remote debugger and the interactive shell, call the subroutine. In particular, it is useful for source-level remote debugging where you need to symbolically track the subroutine calls of specific tasks and symbolic disassemblies for loaded modules.

The execution module manager 360 largely supports a function of loading / unloading an executable file in a host system to a target system and managing a loaded module list on the host system. In addition, the execution module manager 360 includes a loader, which is a DLL (Dynamic Linked Library) structure that is easy to support a variety of file formats (for example, COFF, ELF, a.out, etc.) Have When the target server 300 is running, a DLL supporting the corresponding file format is connected to the target server daemon.

The target memory manager 370 may request allocation of memory of the target system when the tools require loading an embedded application. The target memory size that can be used by the tools when the real-time operating system is running can be set in the operating system configuration file, and the target memory manager 370 manages only the size at first and then additionally requests and manages the target system when it is used up. give. In particular, in order to reduce the number of target accesses, a logical cache may be provided and managed by the memory manager. That is, when the loader of the execution module manager 360 performs the relocation, the cache is used as a kind of buffer, and when the relocation is completed, the write module may only write to the target memory once, or assign an attribute for each cache block to execute the execution module. In the case of a text section, the number of target system accesses is reduced by placing an exact copy of the target system in this cache on the host system.

The communication backend manager 330 is composed of respective backends supporting communication such as common service routines, Ethernet, and serial in the backend manager. Each of the backends consists of DLLs so that the backends are linked to the target server daemons depending on the configuration when the target server is running.

The backend protocol 340 is needed to communicate with a target agent. The protocol is commonly applied to Ethernet and serial communication. The backend protocol 340 defines APIs that need to be connected to the target among the tool interface protocol 320 as several protocols according to their functions, so that call / return is repeated between the backend on the host and the target agent. .

FIG. 5 is a classification table according to the function of the tool interface protocol shown in FIG. 4.

The tool interface protocol is generalized to all tools on the host system. Therefore, even if a new tool is added to the current development environment, only the above protocol needs to be used regardless of the processing method in the target server. In addition, the protocol performs the necessary processing by the target server device in order to connect with the target agent, and then calls the back-end protocol as needed and returns the result to the tool. In other words, part of the protocol is also present in the back-end protocol. The protocol is described in detail as follows.

The interface protocol between the tool on the host system and the target server device is largely related to session management function protocols such as the tool connecting / disconnecting to the target server, restarting the target server daemon and target system, and checking the target server list. A target information and target operation function protocol for executing a loaded executable or setting a target agent type, a protocol for managing a symbol table for adding and deleting target system symbol information and symbols related to an executable to be loaded, and a target Memory-related protocols are managed by the memory manager of the target server device to allow writing / reading to and from the target's memory as needed, and debugging functions are maintained while maintaining the context for remote debugging. Performable It is divided into protocols related to context management and debugging, and protocols for performing event management functions that can be exchanged between tools and target server devices and target agents.These protocols are totally 54 in total, and each protocol is defined as a message number. When calling the tool's service, the target server controller uses it as the service number to call the service.

6 is a flowchart illustrating a process in which a target server device operates as a service daemon to provide a service for a tool according to an embodiment of the present invention.

First, in step S510, various configuration information about the target system to be used must be input before starting the target server daemon. This is because when the target server controller 310 is realized as a graphical user interface, it is convenient for the user. First, a method of communication between the target server 212 and the target agent 223 is selected. For example, the Ethernet type gives information such as a target IP address and time out, and the serial type gives information such as transmission speed (bps), port number, and time out.

Subsequently, in step S520, various executable file formats (OMFs) are selected because the target server apparatus can be realized in a structure capable of supporting various executable file formats. That is, the common loading function necessary to load the target system in the execution module manager 360 is placed in the loader, and each OMF reader is realized as a DLL so that the link can be executed when the target server device is driven.

Subsequently, in step S530, after selecting the real-time operating system executable file mounted in the target system to maintain the target system symbol table in the target server device, in step S540, a plurality of target systems may be connected to one host system. Since one target server device, that is, several target server devices per target system, may operate in a daemon format, the target server name may be given as a separator between them. When the setting for driving the target server device is completed in this way, in step S550, a target server start request is made to the target server controller 310.

Next, in step S560, it is determined whether a target server of the same name or the same IP exists.

As a result of the determination in step S560, if the target server exists, the process returns to step S510. If not, in step S570, the set communication backend.dll is driven through the communication backend manager 330. Then, in step S580, a connection is attempted with the target agent 223, which is a corresponding element in the target system of the target server apparatus, and information necessary for the target system, for example, a target memory start address and size used by the tool, etc. It is returned and used to initialize the target server.

Next, in step S590, the corresponding OMF.dll is driven. In step S592, the target operating system executable file is read to code an operating system file.

Finally, in step S594, after initializing the target server internal modules such as error processing, in step S596, the target server daemon is driven.

7 is a flowchart illustrating a process of receiving and servicing a service request from various development tools and a target agent 223 on a host while the target server device operates as a daemon according to an embodiment of the present invention. Is as follows.

First, in step S610, it is determined whether there is a termination request for the target server daemon, and if there is a termination request, the daemon is terminated. If there is no termination request, in step S620, the tool 211 or the target agent 223 on the host system are displayed. ) Is set to the standby state for the event.

The first protocol used by any tool to receive the services of the target server is TOOL_ATTACH of FIG. 5, and when the target server daemon receives the protocol, the target server daemon allocates a delimiter for distinguishing tools. In step S630, the target server determines the service requested by any tool first.

As a result of the determination in step S630, if it is the first request, in step S640, the service is found and the related process is performed. In step S642, a separator for distinguishing it from the service request of another tool is provided. Will return.

As a result of the determination in step S630, if it is not the first request, in step S650, it is determined whether the event arrives from the target system or the service request after the tool 211 on the host system is connected to the target server daemon.

As a result of the determination in step S650, if the event arrives at the target system, the controller returns to step S620 after delivering to the tool in step S660, and if requested by the tool, finds the corresponding service in step S670, and then In step S672, the identifier of the tool received as the service request argument is checked, and in step S674, the desired service is provided to the tool, and the flow returns to step S620.

As shown in Fig. 7, the target server daemon always waits for the next service request after receiving the tool and the target event.

FIG. 8 illustrates a process of loading and executing embedded software cross-compiled in a host using a target server device to express a relationship between elements in another target server device according to an embodiment of the present invention. As a flow chart, this will be described in detail as follows.

First, after cross-compilation, tools such as remote debuggers and interactive shells load this executable into the target system and test it on the host system to find the program's error. To this end, in step S710, the host development tools 211 request a service (OBJ_MODULE_LOAD) using service related to the execution file loading, and the target server controller calls the corresponding API. The module that solves this in the target server is a reader that can be read according to the loader and executable file format of the execution module manager 360 in FIG.

Subsequently, in step S720, when the loader requests information about the executable file from a reader capable of decoding the executable file according to the executable file format, in step S730, the reader reads the header and returns information about the file to the loader. Then, in step S740, the reader requests the symbol table manager to add the relevant executable file related symbols.

Subsequently, in step S750, the symbol table manager 350 adds a symbol, where the symbol is classified into various types and designed to store an ID to distinguish it from a symbol associated with another executable file. After the symbol table manager 350 stores the symbols, in step S760, the loader requests segment information such as text and data from the reader.

Subsequently, in step S770, when the reader returns segment information and requests the target memory manager 370 to store the cache for each segment, in step S780, it is determined whether relocation is necessary, and if relocation is necessary, step S790 In step S792, the loader performs relocation, otherwise, in step S792, the target memory manager 370 should calculate the segment address to secure the required memory size. At this time, if the target memory size fixedly allocated for use by the tool is insufficient, additional memory is allocated and added to the memory pool managed by the target memory manager 370.

Then, after the memory for writing each segment to the target is secured, in step S794, the target memory manager 370 writes to the communication backend manager 330 at an address calculated by the target memory manager 370. After making the request, after loading the embedded software from the host system to the target system, in step S796, the tool 211 on the host system makes a request for execution using the tool interface protocols (FUNC_CALL, DIRECT_CALL) related to execution. If the loaded software works well on the target system, and if a problem is found, it can be solved using the corresponding protocol provided by the target server device.

The present invention as described above is recorded on a computer-readable recording medium, and can be processed by a computer.

As described in detail above, the target server device of the present invention is responsible for all communication between the tool and the host system, symbol table management, target memory management, and executable file management, so that tools are required for remote development by accessing the target system. This solves all the functions by using the tool interface protocol, which makes it very easy to add new tools.

In addition, since the target server device centralizes and manages the channel between the tool and the target system, the resource of the target system is saved, and the number of host-target communication is reduced through the symbol table manager and the target memory manager of the target server device. It can be effected.

The technical spirit of the present invention has been described above with reference to the accompanying drawings, but this is by way of example only and not by way of limitation to the present invention. In addition, it is obvious that any person skilled in the art may make various modifications and imitations without departing from the scope of the technical idea of the present invention.

Claims (16)

In the target server control device for remote development of embedded real-time software running on the target system using a development tool on the host system, A target server controller configured to reflect the preset flag and to operate the target server according to its characteristics, and to interpret a function requested by a tool on the host system and to call a service corresponding thereto; A tool interface protocol providing an interface for connecting the tool; A symbol table manager that manages information about a system symbol table of the target system and subroutines, variables, and module ids of all execution modules loaded in the target system according to a service called by the target server controller. Wow; An execution module manager configured to load / unload an execution module in the host system to a target system and to manage the loaded execution module file on the host system to make an executable form; A target memory manager for managing a memory used by the tool of the target system; And a communication backend manager configured to allow the target system to communicate with the tools on the host system when the target server is running. The method of claim 1, And the target memory manager comprises a logical cache to reduce the number of accesses of the target system. The method of claim 1, The execution module manager, If the module list loaded in the target system is a file of various formats, the target server device characterized in that it comprises a loader for supporting a file format corresponding to the driving of the target server. In a method of controlling a target server to remotely develop embedded real-time software operating in a target system using a development tool on a host system, A first step of driving the target server according to a characteristic by reflecting a preset flag, interpreting a function requested by a tool on the host system, and calling a service corresponding thereto; According to the service called in the first step, the information on the system symbol table of the target system and the subroutines, variables, and module ids of all the execution modules loaded on the target system is managed to execute the executable file on the host system. And loading and unloading the target system, and then managing the loaded module list on the host system. The method of claim 4, wherein And a third step of allocating a memory to be used when the tool of the target system requests loading of an embedded application and performing a logical cache function to reduce the number of accesses. . A target server device that enables remote development of embedded real-time software running on a target system using a development tool on a host system is provided in a tool on the host system. In order to act as a service daemon (Service Demon) to service the A first step of inputting various setting information about the target system and selecting a communication method according to a communication method of a target agent performing a function of communicating with a target server of the host system; After selecting the executable file format (OMF: Object Module Format) to be converted according to the configuration information input in the first step and the information input from the development tool on the host system, select an operating system file of the target system, A second step of making an operation start request of the target server; If there is a request to start operation in the second step, the target server and the target agent are connected, and necessary information is transmitted to the target server, and then the operating system executable file of the target system is read and the target system is read. And a third step of creating a symbol table and initializing the target server to drive a target server daemon. The method of claim 6, The first step is, If the communication method between the target server and the target agent is an Ethernet method, information such as a target IP address and a timeout is provided, and if a serial method, information such as a transmission speed, a port number, and a timeout is provided. Service daemon operating method of the target server device, characterized in that. The method of claim 6, The second step, If a plurality of target systems are connected to one host system, a target step comprising the step of assigning each target server name so that one target server device in each target system can operate in the form of daemon How the service daemon works on server devices. The method of claim 6 or 8, The third step, And if there is a target server of the same name or the same IP after the operation start request in the second step, returning to the first step. In the target server (Target Server) device, cross-compile (Cross Compile) embedded software on the host system by loading the target system in a remote development method, A first step of extracting decodable information and symbols related to the executable file when the development tools on the host system request a service; A second step of extracting segment information such as text and data related to the information and symbol extracted in the first step and loading embedded software; And a third step of performing an accuracy test by executing the embedded software loaded in the second step. The method of claim 10, The first step is, And a sub-step of assigning a unique ID to each symbol in order to distinguish a symbol to be extracted from a symbol associated with another executable file. The method of claim 10 or 11, The second step, A first sub step of determining whether relocation is required for each segment after storing the extracted segment information in a cache; As a result of the determination in the first sub-step, if relocation is necessary, after relocation is performed for each segment, each segment address is calculated to write, and if relocation is not necessary, the embedded software is immediately Remote development method of embedded software using the target server device, characterized in that it comprises a second sub-step of loading. Target server and development tool on the host system for remote development of embedded real-time software running on the target system using a development tool on the host system To communicate with the field, It can be input, modified, inquired and deleted to indicate the connection and disconnection status between the development tool on the host system and the target server, restart the target server daemon and the target system, or check the list of the target server. A session management area; Target information that can be entered, modified, inquired, and deleted to execute an executable file loaded on the target system or to set a type of a target agent to be in communication with the real-time kernel of the embedded server and the target server of the host; A target operation area; A symbol management area capable of inputting, modifying, retrieving, and deleting the target system symbol information and a table of symbols related to executable files to be loaded; A memory-related area capable of inputting, modifying, viewing, and deleting a part of the memory of the target system as necessary to perform writing and reading; A context management and debugging area capable of inputting, modifying, viewing, and deleting to perform debugging functions while maintaining a context; Target server characterized in that it comprises an event management area that can be input, modified, inquired and deleted for event management that can be exchanged between the development tool on the host system, the target server device and the target agent. And recording data in which communication data with the development tools on the host system is recorded. A target server control program can be executed to remotely develop embedded real-time software running on a target system using a development tool on a host system. In the computer-readable recording medium, A first step of driving the target server according to a characteristic by reflecting a preset flag, interpreting a function requested by a tool on the host system, and calling a service corresponding thereto; According to the service called in the first step, the information on the system symbol table of the target system and the subroutines, variables, and module ids of all the execution modules loaded on the target system is managed to execute the executable file on the host system. And a second step of managing the loaded module list on the host system after loading / unloading the target system. A target server device that enables remote development of embedded real-time software running on a target system using a development tool on a host system is provided in a tool on the host system. In a computer-readable recording medium that records a program that operates as a service daemon to service a service, A first step of inputting various setting information about the target system and selecting a communication method according to a communication method of a target agent performing a function of communicating with a target server of the host system; After selecting the executable file format (OMF: Object Module Format) to be converted according to the configuration information input in the first step and the information input from the development tool on the host system, select an operating system file of the target system, A second step of making an operation start request of the target server; If there is a request to start operation in the second step, the target server and the target agent are connected, and necessary information is transmitted to the target server, and then the operating system executable file of the target system is read and the target system is read. And a third step of creating a symbol table and initializing the target server to drive a target server daemon. A computer-readable recording medium having recorded thereon a program for remote development by loading embedded software cross-compiled on a host system by using a target server device in a target system, A first step of extracting decodable information and symbols related to the executable file when the development tools on the host system request a service; A second step of extracting segment information such as text and data related to the information and symbol extracted in the first step and loading embedded software; And a third step of performing an accuracy check by executing the embedded software loaded in the second step.