Software execution tracing device and program

WO2026190999A1PCT designated stage Publication Date: 2026-09-17NT T INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/JP2025/009359
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-03-12
Publication Date
2026-09-17

Smart Images

  • Figure JP2025009359_17092026_PF_FP_ABST
    Figure JP2025009359_17092026_PF_FP_ABST
Patent Text Reader

Abstract

A software execution tracing device (1) comprises: a system call tracing unit (312) that records a system call instructed from a program in user space to the kernel; a determination unit (330) that determines whether a prescribed system call for starting a kernel thread has been recorded by the system call tracing unit; a kernel internal tracing unit (322) that records execution of a kernel function; and a kernel internal tracing cancellation unit (323) that cancels the recording of the execution of the kernel function if a prescribed end condition is met.
Need to check novelty before this filing date? Find Prior Art

Description

Software execution tracer and program

[0001] The present invention relates to a software execution tracing device and program, and more particularly to a software execution tracing device and program in a computer system.

[0002] In computer systems, there are cases where a computer (hereinafter referred to as a server) acquires and records events caused by user programs. Figure 9 is a schematic diagram of a conventional server 1001. Server 1001 comprises a server machine 10 and software that runs inside it. The software includes a kernel space 170 on which the operating system (OS kernel) runs, and a user space 150 on which the user application 251 runs. The hardware 100 includes a CPU (Central Processing Unit) 110 and memory 130. Here, in the diagram, interfaces are labeled "IF".

[0003] The kernel common section 230 of kernel space 170 includes, for example, kernel function F1 and kernel function F2. Kernel function F1 creates a thread (for example, user thread 252) that operates in user space 150 after system call A is called. This kernel function F1 creates a thread (for example, kernel thread 271) that operates in kernel space 170 after system call B is called. Kernel function F2 terminates user thread 252 after user thread 252 calls system call C.

[0004] System calls can result in events occurring in user space 150 or kernel space 170 after they are invoked. In Figure 9, the dashed arrow R1 schematically shows that after system call A is invoked, the subsequent events occur in user space 150. The solid arrow R2 schematically shows that after system call B is invoked, the subsequent events occur in kernel space 170. Events E1 to E4 are examples of events that require measurement.

[0005] As technologies for acquiring data of events caused by user programs, there are the following three existing technologies. ・System call tracing (eBPF / strace / ptrace) (see Non-Patent Document 1) ・Tracing of kernel common functions (kfunc) (eBPF) (see Non-Patent Document 1) ・Periodic acquisition of management information in the OS (periodic acquisition by the ps command, and acquisition by journald) (see Non-Patent Document 2)

[0006] “What is eBPF? An Introduction and Deep Dive into the eBPF Technology”, [online], [retrieved November 22, Reiwa 6], Internet <URL:https: / / ebpf.io / what-is-ebpf / >, “ps(1) - Linux manual page”, [online], [retrieved November 22, Reiwa 6], Internet <URL:https: / / man7.org / linux / man-pages / man1 / ps.1.html>

[0007] When acquiring and recording events caused by user programs, it is necessary to consider the requirements for comprehensiveness and low overhead shown below. Here, comprehensiveness means that events generated by user applications can be acquired without any omissions. In addition, low overhead means that the measurement range associated with event acquisition is minimized. Specifically, low overhead means that the "period" and "range" for acquiring events are minimized.

[0008] Conventional technologies have gaps with the requirements at each event data acquisition location (trace location). Here, let's consider three data acquisition locations, for example. If the first trace location is the system call interface 210 shown in Figure 9, then strace / ptrace / eBPF can be used as conventional technologies. These conventional technologies can acquire the start event E1 and the end event E2 of the user thread 252 related to path R1. They can also acquire the start event E3 of the kernel thread 271 related to path R2. However, after the kernel thread 271 is created, path R2 does not pass through the system call interface 210. Therefore, these conventional technologies cannot detect the end event E4 of the kernel thread 271 and miss events. Consequently, conventional technologies do not meet the requirement of comprehensiveness.

[0009] If the second trace location is the kernel common section 230 shown in Figure 9, it is possible to use an eBPF probe as a conventional technique. However, this conventional technique acquires all information other than the target user application 251, resulting in overhead. Therefore, the conventional technique does not meet the low overhead requirement.

[0010] If the third tracing location is OS internal management information (thread list information 290 shown in Figure 9), conventional techniques such as periodic execution of the ps command, auditd, or journald can be used. Periodic execution of the ps command does not satisfy the comprehensiveness requirement because it misses events if thread start and end are completed within the period. Journald and similar tools trace all items, resulting in overhead and failing to satisfy the low overhead requirement. Therefore, there is currently no technique that satisfies both the comprehensiveness requirement and the low overhead requirement.

[0011] Therefore, in view of the above circumstances, the present invention aims to acquire events resulting from system calls invoked by user applications without any omissions and with low overhead.

[0012] The software execution tracing device according to the present invention is characterized by comprising: a system call tracing unit that records system calls that instruct the kernel from a user-space program; a determination unit that determines whether or not a predetermined system call that starts a kernel thread has been recorded by the system call tracing unit; a kernel internal tracing unit that records the execution of a kernel function; and a kernel internal tracing release unit that releases the recording of the execution of a kernel function by the kernel internal tracing unit when a predetermined termination condition is met.

[0013] According to the present invention, events resulting from system calls invoked by user applications can be acquired without omissions and with low overhead.

[0014] This is a schematic diagram of the software execution tracing device according to the first embodiment of the present invention. This is an example of information managed by the system call list recording unit. This is an example of displaying thread startup and termination. This is a diagram of the initial setup operation. This is a diagram of the tracing operation of the pre-stage tracing unit. This is a diagram of the termination detection operation by tracing of the post-stage tracing unit. This is a flowchart of the internal processing of the determination unit. This is a schematic diagram of the software execution tracing device according to the second embodiment of the present invention. This is a diagram of the initial setup operation. This is a diagram of the termination detection operation by tracing of the post-stage tracing unit. This is a diagram of the tracing operation of the pre-stage tracing unit. This is a hardware configuration diagram showing an example of a computer that realizes the functions of the software execution tracing device according to the embodiment. This is a schematic diagram of a conventional server.

[0015] The software execution tracing device according to this embodiment will be described in detail below with reference to the drawings. Components identical to those shown in Figure 9 are denoted by the same reference numerals, and their descriptions are omitted as appropriate.

[0016] The software execution tracing device 1 shown in Figure 1 is a device that traces the execution of software in a software system that has multiple data acquisition points in the kernel space 170 within memory 130. Here, the software system is, for example, a vRAN (virtual Radio Access Network) that implements a RAN (Radio Access Network) base station using software and a general-purpose server. In this case, the server machine 10 is a general-purpose server.

[0017] The software execution tracing device 1 comprises a server machine 10 and software that operates within it. The software includes a kernel space 170 as an operating system and a user space 150 that operates on top of the hardware 100.

[0018] The hardware 100 includes a CPU 110, an expansion device 120, and memory 130. The memory 130 has a memory area used as kernel space 170 and a memory area used as user space 150. The user application 251 uses the expansion device 120 via a device driver in the OS. The user application 251 uses system calls to give instructions to the OS kernel.

[0019] The kernel common section 230 in kernel space 170 is a basic operating system that all general-purpose servers have in common. The kernel common section 230 includes, for example, a thread start function 231 and a thread termination function 232.

[0020] The thread initiation function 231 creates a thread that operates in user space 150, for example, a user thread 252, after the user thread initiation system call 211 is called. The thread initiation function 231 also creates a thread that operates in kernel space 170, for example, a kernel thread 271, after the kernel thread initiation system call 212 is called. For example, "copy_process" is the thread initiation function 231.

[0021] The thread termination function 232 terminates the user thread 252 after it has called the process termination system call 213. For example, "do_exit" is the thread termination function 232. The OS kernel provides several system calls.

[0022] The user thread initiation system call 211 is a system call that initiates a user thread 252 in user space 150 by instructing the kernel from a program in user space 150. For example, [clone] is the user thread initiation system call 211. The kernel thread initiation system call 212 is a system call that initiates a kernel thread 271 in kernel space 170 by instructing the kernel from a program in user space 150. For example, [io_uring] is the kernel thread initiation system call 212. The process termination system call 213 is a system call that terminates a process. For example, [exit] is the process termination system call 213. Note that the number of system call types is arbitrary.

[0023] The software execution tracing device 1 includes a data acquisition control unit 30 that traces the execution of server software that constitutes, for example, one of the base stations of a RAN. As shown in Figure 1, the data acquisition control unit 30 includes a pre-trace unit 310, a post-trace unit 320, and a determination unit 330.

[0024] The pre-trace trace unit 310 includes a system call trace setting unit 311 and a system call trace unit 312. The post-trace trace unit 320 includes a kernel internal trace setting unit 321, a kernel internal trace unit 322, and a kernel internal trace release unit 323.

[0025] In the preceding trace unit 310, the system call trace setting unit 311 instructs the system call trace unit 312 to record the kernel thread startup system call 212. The list of system calls to be recorded may be obtained from the system call list recording unit 340, which will be described later.

[0026] In the preceding trace unit 310, the system call trace unit 312 records the user thread initiation system call 211 and the kernel thread initiation system call 212. Here, the system call trace unit 312 hooks the system call interface 210 to detect and record the user thread initiation system call 211 and the kernel thread initiation system call 212.

[0027] The system call trace unit 312 records user thread startup system calls 211 and kernel thread startup system calls 212 based on instructions from the system call trace setting unit 311. The system call trace unit 312 corresponds to the system call tracing function unit using eBPF in the Linux OS. In Figure 1, the dotted line Tr1 indicates the trace destination by the system call trace unit 312.

[0028] The user thread initiation system call 211 initiates a user thread 252 in user space 150. When user thread 252 is created by the user thread initiation system call 211, user thread 252 becomes a trace target of the system call trace unit 312. The kernel thread initiation system call 212 initiates a kernel thread in kernel space 170. The kernel thread initiation system call 212 initiates kernel thread 271 in kernel space. When kernel thread 271 is initiated by the kernel thread initiation system call 212, this kernel thread 271 becomes a trace target of the kernel internal trace unit 322.

[0029] In the subsequent tracing unit 320, the kernel internal trace setting unit 321 sets the kernel internal trace unit 322 to record the execution of kernel functions. Based on instructions from the determination unit 330, the kernel internal trace setting unit 321 sets the kernel internal trace unit 322 to start recording the execution of kernel functions. The kernel function execution recording process, which is a process of the subsequent tracing unit 320, is executed by the kernel internal trace unit 322.

[0030] In the subsequent trace unit 320, the kernel internal trace unit 322 records the execution of kernel functions. Based on instructions from the kernel internal trace setting unit 321, the kernel internal trace unit 322 starts recording the execution of kernel functions. The kernel internal trace unit 322 corresponds to the kfunc (kernel function) tracing function in functional units such as eBPF in the Linux OS. In Figure 1, the dotted line Tr2 indicates the trace destination by the kernel internal trace unit 322.

[0031] In the subsequent trace unit 320, the kernel internal trace release unit 323 releases the recording of kernel function execution by the kernel internal trace unit 322 when a predetermined termination condition is met. For example, the predetermined condition can be that the kernel internal trace unit 322 detects the execution of a kernel function related to the termination of a kernel thread. In this embodiment, as an example, the kernel internal trace release unit 323 releases the recording of kernel function execution when the kernel internal trace unit 322 detects the target kfunc event. The kernel internal trace release unit 323 instructs the kernel internal trace unit 322 to release the recording of kfunc (kernel function) execution in functional units such as eBPF in the Linux OS.

[0032] The determination unit 330 determines whether or not to record the execution of the kernel function based on the system call recording results by the system call trace unit 312. The determination unit 330 determines that it is necessary to record the execution of the kernel function if the kernel thread startup system call 212, which was set in advance by the system call trace setting unit 311, is recorded by the system call trace unit 312.

[0033] In the first embodiment, whether or not it is necessary to record the execution of a kernel function means whether or not it is necessary to start tracing a kernel thread. After the determination unit 330 determines that it is necessary to start tracing a kernel thread, the kernel internal trace unit 322 starts recording the execution of a kernel function.

[0034] In the first embodiment, if the determination unit 330 determines that it is necessary to record the execution of the kernel function, the subsequent trace unit 320, via the kernel internal trace setting unit 321, causes the kernel internal trace unit 322 to start recording the execution of the kernel function.

[0035] The kernel internal trace setting unit 321 of the downstream trace unit 320 sets instructions to the kernel internal trace unit 322 to increase or decrease the target kernel threads, according to the system call recording results by the system call trace unit 312. Specifically, for example, suppose that at a certain time t1, the downstream trace unit 320 detects a system call that requires recording the execution of a kernel function, and that system call is associated with kernel thread TID2. In this case, a measurement range for acquiring events of kernel thread TID2 is set. If, while kernel thread TID2 is running, another system call that requires recording the execution of a kernel function is detected, and that system call corresponds to kernel thread TID3, then kernel thread TID3 is added to the measurement range. Such a situation corresponds to an increase in the target kernel threads. Also, if kernel thread TID3 is running and a parent-child relationship is created by copying kernel thread TID3, this also corresponds to an increase in the target kernel threads. Furthermore, if kernel thread TID3 terminates its operation and stops recording the execution of kernel functions, this corresponds to a decrease in the target kernel threads.

[0036] The determination unit 330 identifies kernel threads 271 whose kernel function execution needs to be recorded by referring to the necessity of recording kernel function execution at other locations that have been registered in advance. The determination unit 330 can quickly determine whether or not to record kernel function execution by referring to this necessity record. When the system call trace unit 312 records a specific system call, the determination unit 330 causes the kernel internal trace setting unit 321 to start recording kernel function execution.

[0037] In this embodiment, the data acquisition control unit 30 includes a system call list recording unit 340, as shown in Figure 1. The system call list recording unit 340 manages a list of system calls that require kernel internal tracing. The system call list recording unit 340 manages a list of system calls recorded by the system call trace unit 312 that require recording of kernel function execution by the kernel internal trace unit 322.

[0038] The system call list recording unit 340 records information relating kernel functions that indicate predetermined processing content that needs to be recorded by the kernel internal trace unit 322 to system calls recorded by the system call trace unit 312. The kernel thread initiation system call 212 initiates a kernel thread in kernel space 170. The determination unit 330 identifies the kernel function to be traced that corresponds to the kernel thread initiation system call 212, based on the system call history recorded by the system call trace unit 312 and the information recorded in the system call list recording unit 340.

[0039] Next, the information managed by the system call list recording unit 340 will be explained with reference to Figure 2. The management information is configured by associating information on system calls that are traced by the preceding trace unit 310 with information on kernel functions that are traced by the succeeding trace unit 320. For example, in the information shown in tabular format in Figure 2, the system call identifier as a key is associated with the trace location of the succeeding trace unit 320. Here, the trace location of the succeeding trace unit 320 is identified by the kernel function name kfunc. The system call identifier may be a system call number instead of a system call name. Note that the data format of this management information is not limited to tabular format; for example, CSV (Comma-Separated Values) or XML (Extensible Markup Language) may also be used.

[0040] The kernel internal trace setting unit 321 of the subsequent trace unit 320 detects the start and end of kernel threads 271 in kernel space from the kernel internal trace unit 322. At the timing of the start and end of kernel threads 271, the kernel internal trace setting unit 321 causes a predetermined display unit to display that kernel threads 271 have started or ended. The display unit may be a monitor device attached to the server machine 10, or an external device connected via a communication network.

[0041] Here, an example of displaying thread startup and shutdown will be explained with reference to Figure 3. Figure 3 shows an example of displaying thread startup and shutdown in the CUI (Character User Interface). Each process information is displayed along with a parent-child relationship tree. For example, the process with PID-1 has threads with TID-2 and TID-3, and the TID-3 thread includes a parent-child relationship. The timing of thread startup and shutdown for each process is displayed, for example, in UNIX time. Note that Figure 3 is a schematic diagram, and in the display example, the two “XXX” have different values. Also, the multiple “UNIXTIME” values ​​may differ.

[0042] [Operation of the Software Execution Trace Device] Next, the operation of the software execution trace device 1 will be explained with reference to Figures 4A to 4C (and Figure 1 as appropriate). Figure 4A shows the initial setup operation. Figure 4B shows the tracing operation of the pre-stage trace unit 310. Figure 4C shows the termination detection operation by tracing of the post-stage trace unit 320.

[0043] Before operation, the software execution trace device 1 performs initial setup in the pre-trace unit 310, as shown in Figure 4A. Specifically, the system call trace setting unit 311 sets the system call trace unit 312 to record kernel thread startup system calls 212, such as [io_uring].

[0044] Thereafter, when the software execution tracing apparatus 1 is in operation, as shown in FIG. 4B, first, the system call tracing unit 312 of the pre-stage tracing unit 310 records a user thread activation system call 211 and a kernel thread activation system call 212.

[0045] Next, the determination unit 330 determines whether it is necessary to record the execution of the kernel function. At this time, as shown in FIG. 5, the determination unit 330 refers to the system call list (FIG. 2) managed by the system call list recording unit 340 (step S331). Then, the determination unit 330 determines whether or not a kernel function that is a tracing target of the post-stage tracing unit 320 is registered for the system call detected by the system call tracing unit 312 (step S332).

[0046] For example, consider a case where the "clone" system call is detected by the system call tracing unit 312. In the system call list recording unit 340 of FIG. 2, no kernel function to be traced by the post-stage tracing unit 320 corresponding to the "clone" system call is registered. When the determination unit 330 thus determines that no kernel function corresponding to the detected system call is registered (step S332: No), the processing for the system call detected by the system call tracing unit 310 is ended.

[0047] On the other hand, consider a case where, for example, the "io_uring_setup" system call is detected by the system call tracing unit 312 in step S332. In the system call list recording unit 340 of FIG. 2, the "do_exit" kernel function to be traced by the post-stage tracing unit 320 corresponding to the "io_uring_setup" system call is registered. When the determination unit 330 determines that a kernel function corresponding to the detected system call is registered in this manner (step S332: Yes), it passes the process to the internal kernel trace setting unit 321 of the post-stage tracing unit 320 (step S333). Then, the process for the system call detected by the system call tracing unit 312 is terminated. Note that the determination unit 330 notifies the internal kernel trace setting unit 321 of information on the kernel function to be traced by the post-stage tracing unit 320.

[0048] Then, when recording of a kernel function by the post-stage tracing unit 320 is necessary, as shown in FIG. 4B, the post-stage tracing unit 320 performs settings for starting recording of the kernel function. That is, the internal kernel trace setting unit 321 sets the internal kernel tracing unit 322 to record, for example, the execution of the "do_exit" kernel function. Accordingly, the internal kernel tracing unit 322 records the execution of the "do_exit" kernel function.

[0049] Then, as shown in FIG. 4C, the post-stage tracing unit 320 terminates the recording of the execution of the kernel function. That is, when the internal kernel trace cancellation unit 323 detects, by the internal kernel tracing unit 322, a kernel function related to termination of a kernel thread 271, the internal kernel trace cancellation unit 323 cancels the recording of the execution of the kernel function by the internal kernel tracing unit 322. Accordingly, the software execution tracing apparatus 1 can minimize the measurement range associated with acquisition of event information. Note that the termination condition for the internal kernel trace cancellation unit 323 is not limited to those described above. The cancellation of recording of execution of the kernel function may be performed after a certain period of time elapses, instead of being performed upon detection of execution of a specific system call.

[0050] (Second Embodiment) Next, a software execution tracing device according to the second embodiment will be described with reference to Figure 6. Note that components identical to those shown in Figure 1 are denoted by the same reference numerals and their descriptions are omitted. The software execution tracing device 1B includes a data acquisition control unit 30B that traces the execution of server software. As shown in Figure 6, the data acquisition control unit 30B includes a pre-trace unit 310, a post-trace unit 320B, a system call list recording unit 340, and a determination unit 350.

[0051] The subsequent trace unit 320B includes a kernel internal trace setting unit 321B, a kernel internal trace unit 322, and a kernel internal trace release unit 323.

[0052] The kernel internal trace setting unit 321B pre-instructs the kernel internal trace unit 322 to continuously record the execution of kernel functions. If the determination unit 350 determines that history information of kernel function execution is necessary, the kernel internal trace setting unit 321B obtains the kernel function history recorded by the kernel internal trace unit 322 from the start to the end of the kernel thread.

[0053] The determination unit 350 determines whether it is necessary for the kernel internal trace unit 322 to record the execution of kernel functions, in accordance with the system calls recorded by the system call trace unit 312. If the history of the kernel thread startup system call 212 set by the system call trace setting unit 311 is recorded, the determination unit 350 determines that kernel function execution history information for kernel thread 271 is necessary.

[0054] In the second embodiment, the determination of whether or not the kernel function execution history is necessary means the determination of whether or not the kernel function history is necessary to refer to. When the determination unit 350 performs the determination process, the execution of the kernel function is recorded.

[0055] [Operation of the Software Execution Trace Device] Next, the operation of the software execution trace device 1B will be explained with reference to Figures 7A to 7C (and Figure 6 as appropriate). Figure 7A shows the initial setup operation. Figure 7B shows the termination detection operation by tracing of the downstream trace unit 320. Figure 7C shows the tracing operation of the upstream trace unit 310.

[0056] Before operation, the software execution trace device 1B performs initial setup in the pre-trace unit 310 and the post-trace unit 320B, as shown in Figure 7A. Specifically, the system call trace setting unit 311 sets the system call trace unit 312 to record the history of kernel thread initiation system calls 212, such as [io_uring]. In addition, the kernel internal trace setting unit 321B instructs the kernel internal trace unit 322 to start continuous recording limited to kernel functions (e.g., "do_exit") corresponding to the pre-configured kernel thread initiation system calls 212. As a result, the software execution trace device 1B records all the information of some kernel functions (e.g., "do_exit") in chronological order.

[0057] In some systems, the processing load for adding and deleting eBPF probes themselves can be substantial. For such cases, the software execution trace device 1B of the second embodiment is suitable. Furthermore, in such cases, reducing the number of probe additions and deletions is expected to result in lower overhead.

[0058] Following Figure 7A, during operation, the kernel internal trace unit 322 continuously records the execution of kernel functions that are necessary and limited to be traced. In this way, the kernel internal trace unit 322 records the execution of kernel functions that are to be traced (for example, "do_exit"). Then, as shown in Figure 7B, the subsequent trace unit 320B terminates the recording of kernel function executions. That is, when the kernel internal trace release unit 323 detects, for example, a kernel function ("do_exit") that indicates the end of tracing by the kernel internal trace unit 322, it releases the recording of kernel function executions by the kernel internal trace unit 322.

[0059] Meanwhile, as shown in Figure 7C, the software execution trace device 1B's system call trace unit 312 of the preceding trace unit 310 records the user thread startup system call 211 and the kernel thread startup system call 212. Next, the determination unit 350 determines whether or not to acquire data from the subsequent trace unit 320. At this time, the internal processing of the determination unit 350 is the same as the processing shown in Figure 5.

[0060] As shown in Figure 5, the determination unit 350 refers to the system call list (Figure 2) managed by the system call list recording unit 340 (step S331). The determination unit 350 then determines whether or not the kernel function that is the target of tracing by the subsequent trace unit 320 is registered for the system call detected by the preceding trace unit 310 (step S332).

[0061] For example, if the determination unit 350 determines that a kernel function to be traced by the subsequent trace unit 320 is registered (step S332: Yes), it passes the process to the kernel internal trace setting unit 321B of the subsequent trace unit 320 (step S333), and terminates processing for the system call detected by the system call trace unit 312. The determination unit 350 also notifies the kernel internal trace setting unit 321B of the information of the kernel function to be traced by the subsequent trace unit 320.

[0062] Then, if it is necessary to record the execution of a kernel function in the subsequent trace unit 320, as shown in Figure 7C, the kernel internal trace setting unit 321B refers to the result of the kernel internal trace unit 322 recording the execution of the kernel function. The kernel internal trace setting unit 321B then obtains a record of the execution of a kernel function, such as "do_exit". The kernel internal trace setting unit 321B can display the obtained record of the execution of the kernel function on the display unit.

[0063] [Hardware Configuration] The software execution trace device 1 according to this embodiment is implemented by a computer 900 having a configuration such as that shown in Figure 8. The computer 900 has a CPU 901, RAM (Random Access Memory) 902, ROM (Read Only Memory) 903, HDD (Hard Disk Drive) 904, accelerator 905, input / output I / F (Interface) 906, media I / F 907, and communication I / F 908. The accelerator 905 corresponds to the expansion device 120 of the software execution trace device 1 shown in Figure 1.

[0064] The accelerator 905 processes at least one of the data from the communication interface 908 or the data from the RAM 902 at high speed. The accelerator 905 can be of a type that returns the execution result to the CPU 901 or RAM 902 after processing from the CPU 901 or RAM 902 (look-aside type). Alternatively, the accelerator 905 can be of an in-line type that acts as an intermediary between the communication interface 908 and the CPU 901 or RAM 902 to perform processing.

[0065] The accelerator 905 is connected to an external device 915 via a communication interface 908. The input / output interface 906 is connected to an input / output device 916. The media interface 907 reads and writes data to and from the storage medium 917.

[0066] The CPU 901 operates based on programs stored in the ROM 903 or HDD 904, and controls each part of the software execution trace device 1 shown in Figure 1 by executing programs loaded into the RAM 902. This program can also be distributed via a communication line or by recording it on a storage medium 917 such as a CD-ROM. This program is a data acquisition control program that, when executed by the CPU 901, embodies the data acquisition control units 30 and 30B. The ROM 903 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs related to the computer 900's hardware.

[0067] The CPU 901 controls the input / output device 916, which consists of an input unit such as a mouse and keyboard, and an output unit such as a display and printer, via the input / output interface 906. The CPU 901 acquires data from the input / output device 916 via the input / output interface 906 and outputs generated data to the input / output device 916. In addition to the CPU 901, a GPU (Graphics Processing Unit) or the like can also be used as a processor.

[0068] The HDD 904 stores programs executed by the CPU 901 and data used by those programs. The communication I / F 908 receives data from other devices via the communication network and outputs it to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0069] The media interface 907 reads a program or data stored in the storage medium 917 and outputs it to the CPU 901 via the RAM 902. The CPU 901 loads the program related to the desired processing from the storage medium 917 onto the RAM 902 via the media interface 907 and executes the loaded program. The storage medium 917 may be an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical Disk), a magnetic recording medium, or a semiconductor memory.

[0070] For example, when computer 900 functions as software execution trace device 1, CPU 901 realizes the function of software execution trace device 1 by executing a program loaded onto RAM 902. Data from RAM 902 is stored in HDD 904. CPU 901 reads and executes a program related to the target process from storage medium 917. Alternatively, CPU 901 may read a program related to the target process from another device via a communication network.

[0071] [Effects] [1] A software execution trace device comprising: a system call trace unit (312) that records system calls that instruct the kernel from a user-space program; a determination unit (330) that determines whether or not a predetermined system call that starts a kernel thread has been recorded by the system call trace unit (312); a kernel internal trace unit (322) that records the execution of a kernel function; and a kernel internal trace release unit (323) that releases the recording of the execution of a kernel function by the kernel internal trace unit (322) when a predetermined termination condition is met.

[0072] As a result, the software execution tracing device 1 can acquire events resulting from system calls invoked by user applications without any omissions and with low overhead.

[0073] [2] The software execution trace device according to item [1], further comprising a kernel internal trace setting unit (321) that causes the kernel internal trace unit (322) to start recording the execution of kernel functions when the determination unit (330) detects the predetermined system call, wherein the kernel internal trace setting unit (321) sets an instruction to increase or decrease the kernel threads started by the system call to the kernel internal trace unit (322) according to the history of system calls recorded by the system call trace unit (312).

[0074] In this way, the software execution tracing device 1 can increase or decrease the number of kernel threads 271 operating in kernel space according to the system call history. This makes it possible for the software execution tracing device 1 to minimize the tracing within kernel space.

[0075] [3] The software execution trace device according to item [2], characterized in that the determination unit (330) identifies kernel functions for which history recording is required by referring to prior registered information on the necessity of history recording.

[0076] In this way, the software execution tracing device 1 uses pre-registered necessity information to identify the kernel functions that need to be recorded. As a result, the software execution tracing device 1 can acquire events without any omissions and with low overhead.

[0077] [4] The software execution trace device according to item [3], comprising a system call list recording unit (340) that manages information recorded by associating a kernel function that indicates a predetermined processing content for which history recording is required with a system call that starts the kernel thread, wherein the determination unit (330) identifies the kernel function to be recorded in the kernel thread corresponding to the system call based on the history of system calls recorded by the system call trace unit (312) and the information managed by the system call list recording unit (340),

[0078] In this way, the software execution trace device 1 starts tracing the kernel thread 271 only if the kernel function associated with the recorded system call is recorded in the system call list recording unit 340. As a result, the software execution trace device 1 can acquire events resulting from system calls invoked by the user application without any omissions and with low overhead.

[0079] [5] A software execution trace device comprising: a system call trace unit (312) that records system calls that instruct the kernel from a user-space program; a kernel internal trace unit (322) that continuously records the execution of kernel functions; and a determination unit (350) that refers to the execution history of kernel functions for the period from when a predetermined system call that starts a kernel thread is recorded by the system call trace unit (312) until when the execution of a kernel function indicating the termination of the kernel thread is recorded by the kernel internal trace unit (322).

[0080] By doing so, the software execution tracer 1B can continuously record the execution of kernel functions, thereby acquiring all events of the kernel thread 271 in chronological order. The software execution tracer 1B can then refer to the events of the kernel thread 271 as needed, according to the recorded history of system calls.

[0081] [6] The software execution trace device according to item [5], further comprising a kernel internal trace setting unit (321B) that instructs the kernel internal trace unit (322) to continuously record the execution of kernel functions.

[0082] [7] The software execution trace device according to item [1], further comprising a kernel internal trace setting unit (321) that obtains detection results of the start and end of the kernel thread from the kernel internal trace unit (322) and displays the timing of the start and end of the kernel thread on a predetermined display unit.

[0083] By doing so, the operators of the software execution tracing device 1 and its computer system can easily verify events caused by system calls invoked by user applications.

[0084] It should be noted that the present invention is not limited to the embodiments described above, and many modifications are possible within the technical concept of the present invention by those with ordinary skill in the art.

[0085] 1, 1B Software execution trace device 30, 30B Data acquisition control unit 150 User space 170 Kernel space 210 System call interface 211 User thread startup system call 212 Kernel thread startup system call 213 Process termination system call 230 Common part within the kernel 231 Thread start function 232 Thread termination function 251 User application 252 User thread 271 Kernel thread 310 Pre-trace unit 311 System call trace setting unit 312 System call trace unit 320, 320B Post-trace unit 321, 321B Kernel internal trace setting unit 322 Kernel internal trace unit 323 Kernel internal trace release unit 330 Judgment unit 340 System call list recording unit 350 Judgment unit

Claims

1. A software execution tracing device comprising: a system call trace unit that records system calls that instruct the kernel from a user-space program; a determination unit that determines whether or not a predetermined system call that starts a kernel thread has been recorded by the system call trace unit; a kernel internal trace unit that records the execution of a kernel function; and a kernel internal trace release unit that releases the recording of the execution of a kernel function by the kernel internal trace unit when a predetermined termination condition is met.

2. The software execution tracing device according to claim 1, further comprising a kernel internal trace setting unit that, when the determination unit detects the predetermined system call, causes the kernel internal trace unit to start recording the execution of a kernel function, wherein the kernel internal trace setting unit sets instructions to increase or decrease the number of kernel threads started by the system call, according to the history of system calls recorded by the system call trace unit.

3. The software execution trace device according to claim 2, characterized in that the determination unit identifies kernel functions for which history recording is required by referring to previously registered information on the necessity of history recording.

4. A software execution trace device according to claim 3, comprising a system call list recording unit that manages information recorded by associating a kernel function indicating a predetermined processing content for which history recording is required with a system call that starts the kernel thread, wherein the determination unit identifies the kernel function to be recorded in the kernel thread corresponding to the system call based on the history of system calls recorded by the system call trace unit and the information managed by the system call list recording unit.

5. A software execution tracing device comprising: a system call trace unit that records system calls that instruct the kernel from a user-space program; a kernel internal trace unit that continuously records the execution of kernel functions; and a determination unit that refers to the execution history of kernel functions for the period from when a predetermined system call that starts a kernel thread is recorded by the system call trace unit until when the execution of a kernel function indicating the termination of the kernel thread is recorded by the kernel internal trace unit.

6. The software execution trace device according to claim 5, further comprising a kernel internal trace setting unit that instructs the kernel internal trace unit to continuously record the execution of kernel functions.

7. The software execution trace device according to claim 1, further comprising a kernel internal trace setting unit that obtains detection results of the start and end of the kernel thread from the kernel internal trace unit and displays the timing of the start and end of the kernel thread on a predetermined display unit.

8. A program for causing a computer to function as a software execution tracing device according to any one of claims 1 to 7.