JP2020113050A - Dynamic link device, dynamic load device, computer system, dynamic link method, dynamic load method, dynamic link program, and dynamic load program - Google Patents

Abstract

To provide a dynamic link device that allows a program such as an accelerator to link a host shared library without writing a stub.SOLUTION: A dynamic link device includes: load means that loads a shared library into a memory of an own device and links it from a calling source program; and platform switching means that identifies a target of the shared library and switches a function call function of the shared library from the calling source program to the own device or another device.SELECTED DRAWING: Figure 1

Description

The present invention relates to a dynamic link device, a dynamic load device, a computer system, a dynamic link method, a dynamic load method, a dynamic link program, and a dynamic load program.

In today's computer systems, performance improvement by increasing the frequency of general-purpose computers is saturated due to semiconductor technology and power constraints. Therefore, heterogeneous computer systems composed of computers with different characteristics such as accelerators suitable for processing are expanding. As an example, there is a computer system including a host including a general-purpose processor that performs normal calculation and input/output, and an accelerator including a processor suitable for numerical calculation. Some accelerators, such as Intel Xeon Phi (registered trademark) and NEC SX-Aurora TSUBASA (registered trademark), support operating system functions and shared libraries.

The shared library is widely used in computer systems in order to improve software reusability by improving program reusability and reduce storage and memory consumption due to duplicated code depending on functions used in multiple programs. It is popular. Standard operating systems support shared libraries. For example, Linux (registered trademark) and Unix (registered trademark) operating systems support ELF (Executable and Linking Format) and ELF shared object, which are dynamically linkable and dynamically loadable shared libraries.

A heterogeneous computer system starts another computer (accelerator) suitable for a specific process from an execution file that runs on a computer (host) that starts executing a program. This particular process may be provided as a shared library for optimized code reusability.

In a distributed program that operates on multiple computers used in a heterogeneous computer system, when using a function (for example, a function/method) that operates on a computer (hereinafter, also referred to as a server) other than its own computer, RPC (Remote Procedure) Call) is used. In RPC, it is necessary to add complicated description and processing different from the normal function call. For example, when using RPC, the argument passed to the function that the client should call remotely is converted into a chunk of data for transfer called marshalling or serialization, and the converted data is executed. Transfer to the server. The server restores the marshalled or serialized data to the original form (unmarshalling, deserialization), and actually calls the function. The server marshals the result of calling the function and returns it to the client. The client unmarshalls the results returned by the server.

Generally, a client stub and a server stub are used in a program that calls a function of another computer by RPC. The client stub performs marshaling on the client side, issues a request to the server, receives a return value from the server, and returns that value. The server stub receives the request on the server side, unmarshalls it, passes it as an argument to a function on the server, executes the function, and sends the return value to the client. The developer writes a program that calls the client stub and links the client stub.

Non-Patent Document 1 describes ONC (Open Network Computing) RPC as an example of RPC.

Further, Patent Document 1 describes a graphic system including a host and an accelerator connected to the host. This graphic system has a structure management unit in the host library. The client can directly store the structure edit request on the shared memory in the accelerator by the structure management unit.

The technique described in Patent Document 2 determines whether or not there is a substitute library for the host when it is necessary to load the library of the guest platform, and if there is, the substitute library is loaded and used. Further, the technique described in Patent Document 2 uses the guest library by emulation/binary conversion if there is no substitute library for the host.

JP, 09-319856, A Japanese Patent Publication No. 2013-511782

R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification Version 2", [online], August 1995, Request for Comments: 1831 (RFC1831), [Search December 25, 2018], Internet <http://www .ring.gr.jp/pub/doc/RFC/rfc1831.txt>

By automatically generating the client stub and the server stub used for the RPC (hereinafter collectively referred to as a stub), the cost for developing the stub can be reduced. For example, a function interface is described in IDL (Interface Definition Language), and a stub is generated by the IDL compiler. In detail, RPCGEN is known as an IDL compiler used for ONC RPC. RPCGEN is a compiler that uses the interface definition file to generate C language stubs for the server and client.

However, although automatic generation of stubs by IDL reduces the cost of stub development, the stubs still have to be linked programmatically.

The present invention has been made to solve the above problems, and an object thereof is to provide a technique in which an accelerator program can link a shared library of a host without writing a stub.

The dynamic link device of the present invention identifies the load means for loading the shared library into the memory of the device itself and linking it from the calling program and the target of the shared library, and the function call of the shared library from the calling program. Platform switching means for switching the function to its own device or another device.

The dynamic loading device of the present invention identifies the loading means for loading the shared library into the memory of its own device and linking it from the calling program, and the target of the shared library, and the function call of the shared library from the calling program. Platform switching means for switching the function to its own device or another device.

A computer system of the present invention is a computer system including a first information processing device and a second information processing device connected to the first information processing device, wherein the first information processing device is shared. The first means for loading the library into the memory of the first information processing device and identifying the load means for linking from the calling program and the target of the shared library, and the function calling function of the shared library from the calling program Platform switching means for switching to the processing device or the second information processing device.

According to the dynamic linking method of the present invention, the shared library is loaded into the memory of its own device, linked from the calling program, the target of the shared library is identified, and the function of function call of the shared library is called from the calling program. Switch to a device or other device.

According to the dynamic loading method of the present invention, the shared library is loaded into the memory of its own device, linked from the calling program, the target of the shared library is identified, and the function of the shared library function call is automatically executed from the calling program. Switch to a device or other device.

The dynamic link program of the present invention has a function of loading the shared library into the memory of the own device and linking it from the calling program, and a function of identifying the target of the shared library and calling the function of the shared library from the calling program. Causes the computer to execute the function of switching the device to its own device or another device.

The dynamic load program of the present invention has a function of loading the shared library into the memory of its own device and linking it from the calling program, and a function of identifying the target of the shared library and calling the function of the shared library from the calling program. Causes the computer to execute the function of switching the device to its own device or another device.

According to the present invention, the accelerator program can link the shared library of the host without writing the stub.

It is a block diagram which shows the structural example of the dynamic link apparatus which concerns on the 1st Embodiment of this invention. FIG. 3 is a block diagram showing a configuration example of a computer system as an example of an environment in which the dynamic link device shown in FIG. 1 operates. 3 is a flowchart illustrating an operation example (dynamic link method, dynamic load method, dynamic link program, dynamic load program) of the dynamic link device operating on the computer system shown in FIG. 2. FIG. 7 is a diagram showing an example of the layout of the accelerator memory space in the initial state when the program “a.out” is started in the first embodiment. FIG. 8 is a diagram showing an example of the layout of the memory space of the accelerator after the dynamically linked shared library is loaded in the first embodiment. FIG. 9 is a diagram showing an example of arrangement of memory spaces of an accelerator and a host when delay linking of a dynamically linked shared library is completed in the first embodiment. It is a block diagram which shows the structural example of the dynamic link apparatus which concerns on the 2nd Embodiment of this invention. It is a block diagram which shows the structural example of the dynamic load apparatus which concerns on the 3rd Embodiment of this invention. It is a block diagram which shows the structural example of the computer system which concerns on the 4th Embodiment of this invention.

[First Embodiment]
(Description of configuration)
FIG. 1 is a block diagram showing a configuration example of a dynamic link device 10 according to the first embodiment of the present invention. The dynamic link device 10 illustrated in FIG. 1 includes a loading unit 11 (an example of a loading unit) and a platform switching unit 12 (an example of a platform switching unit).

The load unit 11 is a dynamic linker or a dynamic loader that loads the shared library into the memory of the accelerator and links it from the calling program. The load unit 11 loads both a dynamic object serving as a shared library targeting the accelerator and a dynamic object serving as a shared library targeting the host.

The platform switching unit 12 identifies the target of the shared library loaded by the loading unit 11. Further, the platform switching unit 12 switches the function calling function for calling the function of the shared library by the calling source program.

Each of the above units in this embodiment can be realized in hardware or in an environment in which hardware and software are combined. For example, each unit described above can be realized under the environment shown in FIG.

FIG. 2 is a block diagram showing a configuration example of a computer system 20 as an example of an environment in which the dynamic link device 10 shown in FIG. 1 operates. The computer system 20 shown in FIG. 2 includes a host 21 and an accelerator 22. The host 21 and the accelerator 22 are connected via an I/O (Input/Output) interface 23. The host 21 and the accelerator 22 each include one or more processors and memories. In the example illustrated in FIG. 2, the host 21 includes n processors 211-1 to 211-n and a memory 212. The accelerator 22 includes a processor 221 and a memory 222. The host 21 includes a disk device 213. A file system used by the host 21 is constructed by the disk device 213. The disk device 213 stores the operating system of the host 21, programs executed by the host 21 and the accelerator 22, and shared library information. The shared library is dynamically linked to the reading source program.

The host 21 and the accelerator 22 are, for example, devices equipped with hardware that provides information (data, services, etc.) on a network. Here, the hardware is, for example, an electronic circuit such as an IC or an FPGA, or a computer (for example, a device that realizes a function by executing a program stored in a memory by a CPU or a GPU). Alternatively, hardware refers to, for example, a device in which an electronic circuit and a computer are combined. In the above, IC is an abbreviation for Integrated Circuit and FPGA is an abbreviation for Field Programmable Gate Array. CPU is an abbreviation for Central Processing Unit, and GPU is an abbreviation for Graphics Processing Unit.

In the following description, the case where the dynamic link device 10 is implemented in the accelerator 22 will be described. However, this does not limit the first embodiment. The dynamic link device 10 may operate in the host 21. That is, the dynamic link device 10 may operate in either the accelerator 22 or the host 21 (hereinafter, also referred to as the first information processing device or its own device). Then, the dynamic link device 10 calls the function call of the shared library in the first information processing device and a device connected to the first information processing device and the first information processing device (hereinafter, the second information processing device). Or it may be called another device). For example, when the dynamic link device 10 operates in the accelerator 22, the accelerator 22 is the first information processing device and the host 21 is the second information processing device. When the dynamic link device 10 operates in the host 21, the host 21 is the first information processing device and the accelerator 22 is the second information processing device.

(Explanation of operation)
FIG. 3 is a flowchart for explaining an operation example of the dynamic link device 10 operating on the computer system 20 shown in FIG. That is, this flowchart is nothing but the explanation of the dynamic linking method, dynamic loading method, dynamic linking program, and dynamic loading program.

When the program "a.out" is started on the accelerator 22, the loading unit 11 loads the library dynamically linked with the program "a.out" (step S10).

When the dynamically linked library is loaded, the platform switching unit 12 determines whether the target of the library is the host 21 or the accelerator 22 (step S11).

If the target of the library is for the host (Yes in step S11), the platform switching unit 12 requests the host 21 to load the same library (step S14). When the program "a.out" calls a function included in the library of the host 21 after loading the library, the platform switching unit 12 sets to jump to the host stub. Specifically, the platform switching unit 12 sets to jump from a PLT (Procedure Linkage Table) storing a code for calling the function to a host stub (step S15).

On the other hand, if the target of the library is for the accelerator (No in step S11), the platform switching unit 12 executes the initialization process of the library loaded in step S10 (step S12). Further, the platform switching unit 12 sets the GOT (Global Offset Table) to complete the memory rearrangement as shown in FIG. 5 described later (step S13). The processing of steps S12 and S13 is processing that is also executed by a general dynamic linker.

Detailed processing of step S10 shown in FIG. 3 will be described with reference to FIGS. 4 and 5.

FIG. 4 is a diagram showing an arrangement example of the memory space 3 of the memory 222 of the accelerator 22 in the initial state when the program “a.out” is started in this embodiment. “A.out” in this embodiment is, for example, an ELF dynamic link execution file.

As shown in FIG. 4, the memory space 3 of the accelerator 22 is a text area 311 which is an area for holding the header and text of the program “a.out” and an area for storing the data of “a.out”. A data area 312 is arranged. Further, in the memory space 3 of the accelerator 22, a text area 321 holding the header and text of the dynamic linker "ld.so" loaded with the program "a.out" and data of the dynamic linker "ld.so". And a data area 322 for storing

The program “a.out” links the shared library “libhost.so” and calls the function func included in “libhost.so”.

The text area 311 includes a PLT for calling a dynamically linked function. The PLT that calls the function func includes func@plt3111.

In addition, the data area 312 has a GOT 3121 which is an entry corresponding to the function func in “.got.plt” that stores the address of the function in the dynamically linked library. The GOT3121 is used as an operand of the indirect jump instruction stored in the area designated by func@plt. The initial value of GOT3121 is the address of the instruction next to the indirect jump instruction in func@plt3111. This is for use on a delayed link.

The dynamic linker text area 321 includes a shared library stub 3211 and a host stub 3212.

The shared library stub 3211 resolves the address where the function of the predetermined PLT entry is located from the symbol table of the dynamic linker “ld.so” and relocates the PLT. That is, the shared library stub 3211 updates the corresponding entry of “.got.plt” and jumps to the address of the function. After the relocation by the shared library stub 3211, the function in the shared library is called from the PLT by a jump instruction without passing through the shared library stub.

The host stub 3212 notifies the host 21 from the accelerator 22 of the value passed as the argument of the function call together with the function to be called on the host 21 side, and requests the function call on the host 21. As an example, the host stub 3212 marshalls the value of the register defined by ABI (Application Binary Interface) and the address of the function to be called, and transfers it to the host 21 via the I/O interface 23.

The loading unit 11 loads the library requested by the program “a.out”, that is, dynamically linked, from the file system into the memory space 3. Then, the loading unit 11 executes the initialization routine of "a.out". In this embodiment, the text area and data area of “libhost.so” are mapped from the file system on the disk device 213 to the memory space 3 of the accelerator 22.

FIG. 5 is a diagram showing an example of the layout of the memory space 3 of the accelerator 22 after the dynamically linked shared library is loaded by the initialization processing by the dynamic linker “ld.so” in this embodiment. The same regions as those in FIG. 4 are assigned the same numbers as those in FIG. 4, and detailed description thereof is omitted. In the memory space 3 of the accelerator 22 shown in FIG. 5, the text area 311 and the data area 312 of “a.out” and the text area 321 and the data area of the dynamic linker “ld.so” are provided as in FIG. 322 are arranged. Further, in the memory space 3 shown in FIG. 5, a text area 431 for storing a header and text of "libhost.so" and a data area 432 for storing data of "libtest.so" are arranged. The text area 431 includes a function func4311. However, the function func4311 is a binary executed by the host 21, and cannot be executed by the processor 221 of the accelerator 22.

The details of the PLT setting process, that is, the delay link (step S15) by the platform switching unit 12 in the present embodiment will be described with reference to FIG.

FIG. 6 is a diagram showing an example of an arrangement of the memory space 3 of the memory 222 of the accelerator 22 and the memory space 5 of the memory 212 of the host 21 at the time of completion of the delay link performed by the platform switching unit 12 at the time of calling a function in the present embodiment. Is. The same regions as those in FIGS. 4 and 5 are denoted by the same numbers as those in FIGS. 4 and 5, and the description thereof will be omitted. In the memory space 5 of the host 21, a text area 531 of “libhost.so” and a data area 532 are arranged. The text area 531 and the data area 532 are areas loaded by the loading unit 11 in step S14. The text area 531 includes a function func5311. The func stub 541 arranged in the memory space 3 of the accelerator 22 is a stub for calling the function func5311 of the host 21.

When the program "a.out" calls the function func, the accelerator 22 first executes the code of func@plt3111 in the text area 311 of "a.out". In a program that supports dynamic linking, the PLT has an indirect jump instruction to the address held in the ".got.plt" entry and an instruction to set the PLT number and jump to the shared library stub 3211. Is included. Since the entry GOT3121 of “.got.plt” in the data area 312 is not set, the accelerator 22 executes the next instruction by the indirect jump. The processing of the accelerator 22 jumps to the shared library stub 3211.

The processing of the shared library stub 3211 in this embodiment will be described. The shared library stub 3211 retrieves the corresponding address from the symbol table. The platform switching unit 12 identifies whether the text area including the address obtained as a result of the search belongs to the library for the host or the library for the accelerator.

For the accelerator, the platform switching unit 12 updates the GOT 3121 that is the entry of “.got.plt” with the obtained address, as in a general dynamic linker.

For the host, the platform switching unit 12 allocates an area to the memory space 3 of the accelerator 22 and creates a func stub 541. The func stub 541 is an instruction sequence for an accelerator that sets the address of the function func5311 of the host 21 and jumps to the host stub 3212. The address of the function func5311 of the host 21 is set to one of the registers which may be destroyed by the function call on the ABI. Alternatively, the address of the function func5311 of the host 21 may be set at the top of the stack. Alternatively, a TLS (Thread Local Storage) area for one address may be reserved for this purpose. After the platform switching unit 12 creates the func stub 541, the GOT 3121 that is the entry of “.got.plt” is set to the address of the func stub 541, and the accelerator 22 jumps to the host stub 3212. The host stub 3212 calls the function func5311 of the host 21.

In addition, since ".got.plt" is updated in the second and subsequent calls to the function func, the accelerator 22 specifies the address of the function func5311 by the func stub 541 from the PLT, and the host stub 3212 is designated. To jump. As a result, the function func5311 of the host 21 is called from the host stub 3212.

(Explanation of effects)
According to the first embodiment described above, by including the platform switching unit 12, the program of the accelerator 22 can link the shared library of the host 21 without describing the stub.

(Modification)
In the first embodiment described above, the case where the dynamic linker is a standard Linux (registered trademark) dynamic linker is taken as an example. However, this is merely an example, and the first embodiment is not limited to the dynamic linker as described above.

Further, the dynamic loader may operate by using an API (Application Programming Interface) call such as a dropen function instead of loading the program based on the dependency when the program is loaded.

Also, the delayed link is not mandatory. For example, before the first call, the func stub 541 may be generated immediately after the loading, and the “.got.plt” entry may be set to the address of the func stub 541.

Further, depending on ISA (Instruction Set Architecture) or ABI, it may be possible to directly set the stub for the host without preparing the stub for each function (corresponding to the func stub 541). For example, if the function call address (func@plt) remains at the time of jumping to the stub, the corresponding PLT can be known from that address, that is, the function func to be called can be specified.

Further, in the case of the above-described embodiment, it is premised that all the numerical arguments in the general-purpose register may be transferred, but the present embodiment is not limited to this.

For example, the dynamic loader marshalls and sends all the arguments in the ABI in which the arguments are stored in different registers depending on the argument types, such as x86-64. It should be noted that x86-64 is one of the instruction sets obtained by expanding the instruction set architecture of Intel (registered trademark) company to 64 bits.

In addition, the dynamic loader may operate as follows when using debug information of Dwarf or a name-modified function name (for example, C++). That is, the dynamic loader can acquire the type and size of the argument from the information included in the binary, and can copy in and marshal the data when the argument of the structure pointer is present and transfer the data. Dwarf is a widely used standard for debugging data format.

[Second Embodiment]
FIG. 7: is a block diagram which shows the structural example of the dynamic link apparatus 300 which concerns on the 2nd Embodiment of this invention. The dynamic link device 300 includes a loading unit 302 (an example of a loading unit) and a platform switching unit 304 (an example of a platform switching unit).

The loading unit 302 loads the shared library into the memory 222 of the accelerator 22 and links it from the calling program. The platform switching unit 304 identifies the target of the shared library, and switches the function calling function of the shared library from the calling source program to its own device or another device. That is, the loading unit 302 and the platform switching unit 304 operate similarly to the loading unit 11 and the platform switching unit 12, respectively.

According to this embodiment, the program of the accelerator 22 can link the shared library of the host 21 without writing a stub. The reason is that the load unit 302 and the platform switching unit 304 of the dynamic link device 300 operate similarly to the corresponding configurations in the first embodiment.

[Third Embodiment]
FIG. 8: is a block diagram which shows the structural example of the dynamic load apparatus 400 which concerns on the 3rd Embodiment of this invention. The dynamic loading device 400 includes a loading unit 402 (an example of a loading unit) and a platform switching unit 404 (an example of a platform switching unit).

The loading unit 402 loads the shared library into the memory 222 of the accelerator 22 and links it from the calling program. The platform switching unit 404 identifies the target of the shared library and switches the function calling function of the shared library from the calling source program to its own device or another device. That is, the loading unit 402 and the platform switching unit 404 operate similarly to the loading unit 11 and the platform switching unit 12, respectively.

According to this embodiment, the program of the accelerator 22 can link the shared library of the host 21 without writing a stub. The reason is that the load unit 402 and the platform switching unit 404 of the dynamic load device 400 operate similarly to the corresponding configurations in the first embodiment.

[Fourth Embodiment]
FIG. 9 is a block diagram showing a configuration example of a computer system 500 according to the fourth embodiment of the present invention.

The computer system 500 includes a host 600 and an accelerator 700 connected to the host 600.

When the dynamic link device 10 or the like is included in the accelerator 700, the accelerator 700 loads the shared library into the memory of the accelerator 700 and links from the calling program. Further, the accelerator 700 identifies the target of the shared library, and switches the function call function of the shared library from the calling program to the accelerator 700 or the host 600. That is, the accelerator 700 switches the function calling function to the first information processing device or the second information processing device. In this way, the accelerator 700 operates similarly to the accelerator 22.

According to this embodiment, the program of the accelerator 700 can link the shared library of the host 600 without writing a stub. The reason is that the accelerator 700 operates similarly to the accelerator 22 of the first embodiment.

When the dynamic link device 10 and the like are included in the host 600, the host 600 loads the shared library into the memory of the host 600 and links from the calling program. Further, the host 600 identifies the target of the shared library and switches the function calling function of the shared library from the calling program. In this case, the host 600 realizes the same function as the dynamic link device 10 or the like.

The embodiments described above are widely applicable to a heterogeneous computer system that supports a shared library, its operating system, a dynamic linker, a dynamic loader, and the like.

Although the present invention has been described above using each embodiment, the technical scope of the present invention is not limited to the description of each embodiment. It is obvious to those skilled in the art that various changes or improvements can be added to each of the above embodiments. Therefore, it is needless to say that a mode in which such changes or improvements are made is also included in the technical scope of the present invention. Further, the numerical values, the names of the components, and the like used in each of the embodiments described above are merely examples, and can be changed as appropriate. Further, the directions of the arrows in the drawings show an example, and do not limit the direction of signals between blocks.

3 Memory Space 5 Memory Space 10 Dynamic Link Device 11 Loading Unit 12 Platform Switching Unit 20 Computer System 21 Host 22 Accelerator 23 I/O Interface 211-1 to 211-n Processor 212 Memory 213 Disk Device 221 Processor 222 Memory 300 Dynamic Link device 302 Loading unit 304 Platform switching unit 400 Dynamic loading device 402 Loading unit 404 Platform switching unit 500 Computer system 600 Host 700 Accelerator

Claims (8)

Load means that loads the shared library into the memory of the device itself and links from the calling program,
And a platform switching unit that identifies a target of the shared library and switches the function calling function of the shared library from the calling source program to its own device or another device. When the target of the shared library is for its own device, the platform switching means executes initialization processing of the loaded shared library and completes relocation by setting a GOT (Global Offset Table). Item 1. The dynamic link device according to item 1. Load means that loads the shared library into the memory of the device itself and links from the calling program,
A platform switching unit that identifies a target of the shared library and switches a function calling function of the shared library from the calling source program to its own device or another device. A computer system including a first information processing device and a second information processing device connected to the first information processing device,
The first information processing device is
The shared library is loaded into the memory of the first information processing device, linked from the calling program,
A computer system that identifies a target of the shared library and switches the function calling function of the shared library from the calling program to the first information processing apparatus or the second information processing apparatus. Load the shared library into the memory of your device,
Link from the calling program,
Identify the target of the shared library,
A dynamic linking method for switching the function call function of the shared library from the calling program to its own device or another device. Load the shared library into the memory of your device,
Link from the calling program,
Identify the target of the shared library,
A dynamic loading method in which the function of function call of the shared library is switched from the calling program to its own device or another device. A function to load the shared library into the memory of the device itself and link from the calling program,
A dynamic link program that causes a computer to execute a function of identifying a target of the shared library and switching a function calling function of the shared library from the calling source program to its own device or another device. A function to load the shared library into the memory of the device itself and link from the calling program,
A dynamic load program for causing a computer to execute a function of identifying a target of the shared library and switching a function calling function of the shared library from the calling source program to its own device or another device.

Images