JP2637146B2 - Debug system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Summary] The present invention relates to a debug system that dynamically changes the contents of a write-protected space of an OS using a memory management coprocessor that does not have a write-protect release function. In addition, the purpose is to access the write-protected space on the physical memory so that the contents can be changed or referenced without providing a special space management function. System that changes the contents of the write-protected space of the OS using a coprocessor for PMMU (PMMU), obtains the physical address corresponding to the logical address to be converted by the address conversion function of the PMMU, and then obtains the PMMU
Is temporarily invalidated, and a predetermined write-protected space on the physical memory is accessed by a physical address to perform a desired change or reference to the content.

[Industrial applications]

The present invention relates to a debug system that dynamically changes the contents of a write-protected space of an operating system (hereinafter referred to as an OS) using a memory management coprocessor that does not have a write protection release function.

[Conventional technology]

The computer system uses the OS to improve the processing capacity of the entire system, shorten the response time, facilitate the operation and use of the computer, detect and recover from a failure, and the like.

For this reason, in general, in order to guarantee the operating environment of the OS system, an area where the OS exists in the memory space is protected from being accessed due to malfunction and writing or the like is not performed.

When testing or maintaining the OS or the like, it may be necessary to change the contents including the space of the OS itself by debugging or the like. However, when the OS is running, write protection is set for the area in the memory space where the OS exists, so it is not possible to access and change the contents as it is, and complicated processing is required It is. In particular, when the memory management coprocessor has a function of dynamically releasing the write protection, a complicated procedure is required for the content change processing.

Next, with reference to FIGS. 5 to 7, a description will be given of a memory management method of a memory management coprocessor having no dynamic write protection release function and an access method to a write-protected space by debugging or the like.

FIG. 5 is a block diagram showing a basic configuration of a computer system having a memory management co-processor. In the figure, 10 is a CPU board, 21 is a device control adapter for controlling connection with a disk device or a floppy device and data transfer, 22 is a communication control adapter for controlling communication with a line, and 23 is a connection and data transfer with a terminal. Is a terminal control adapter that controls Debug is also connected to this terminal control adapter.

In the CPU board 10, 11 is an instruction processor (MPU)
Controls the operation of the entire system such as the OS.

A memory management coprocessor (PMMU) 12 associates a physical space on an actual physical memory with a virtual logical space. The PMMU 12 has a write protection function for prohibiting writing to the OS or firmware space set by the OS, but does not support a function for dynamically releasing the write protection function. As such a processor,
For example, there is MC68851.

Reference numeral 13 denotes a main storage device (MSU), which is composed of a physical memory in which a physical space is expanded. Reference numeral 14 denotes an internal bus connecting the PMMU 12 and the MSU 13, and reference numeral 15 denotes an external bus connecting the PMMU 22 and each of the control adapters 21 to 23.

In this configuration, the logical memory map of the computer system has a configuration as shown in FIG. In the figure, 31 is a logical space, a firmware space 311, an OS space 31
2 and a general program space 313 and are formed on a virtual logical memory. Each of these spaces is accessed by a logical address.

The firmware space 311 is a space where a control table for debugging and firmware in the system exists, and the like.
Accesses other than firmware and OS, that is, changes and references to contents, are prohibited.

The OS space 312 is a space in which programs and data of the OS are present, and in which general programs, firmware, and all programs including the OS itself are not allowed to change contents. In particular, referring to the contents of a general program is also prohibited.

Reference numeral 313 denotes a general program space, which is a space where general programs such as application programs and commands exist, and all programs are allowed to refer to and change the contents. The area of the general program space 313 is allocated to each user as a use area.

On the other hand, the MSU 13 is a physical memory, in which a physical space accessed by a physical address is expanded.

FIG. 7A shows the physical space 32, which is composed of a firmware area 321, an OS space 322, and a general program space 323, like the logical space. General program space 3
In 23, 323A ₁ and 323A ₂ are regions existing programs A, 323B ₁ ~323B ₃ is the presence region of the program B. As described above, the general programs A, B, and the like are distributed on the general program space 323.

The PMMU 12 refers to the address management table set by the OS and stores each program scattered on the physical space 32 in a firmware for each program as shown in FIGS. 7B and 7C. Space (331,341), OS space (33
2,342) and the general program space (333,343) are linked to the logical space (33,34).

Each program is assigned a logical address, and the logical address can be converted to a corresponding physical address by referring to the address management table.

Thus, each of the programs A and B can operate without being restricted to the actual physical space by accessing with the logical address.

This PMMU12 has no software awareness. That is, there is no distinction between the OS and the firmware and no distinction between these and the general program, but the distinction is based on the execution qualification for the MPU 11.

The execution qualification for the MPU 11 has a privilege and a general, the execution qualification of the OS and the firmware (such as debugging) is a privilege, and the execution qualification of the general program is general. Only programs with the privileged execution qualification can access the OS and firmware space. This protects programs (general programs) with general execution qualifications from accessing the OS or firmware space and changing the contents. In particular, as described above, the OS prohibits the modification of the contents by all programs including the firmware and the OS itself, as well as the general program, and furthermore, prohibits the reference of the contents to the general program. It protects the OS from destruction of the OS itself due to runaway and the access from general programs.

When testing or maintaining the OS, for example, when a bug is found, it is necessary to change the contents of the error including the space of the OS itself by debugging or the like.

However, the PMMU 12 does not support the function of dynamically canceling write protection. For this reason, even if an attempt is made to perform debugging by accessing with a logical address, the writing is prohibited by the write protection function of the PMMU 12 and debugging cannot be performed.

When the operation of the PMMU 12 is invalidated, the write protection function does not work, so that it is possible to access the physical memory (that is, the MSU 13) with the physical address and change the contents thereof. However, since the logical address is given to the operator (user) who performs debugging, the operator cannot know the physical address corresponding to the logical address. Therefore, the physical memory (MSU13) cannot be accessed and its contents cannot be changed as it is.

Therefore, conventionally, a change process for an OS or the like has been performed in the following manner.

A system that does not use the memory protection function of PMMU12.

This method cannot perform the memory protection function for PMMU12,
It is possible to access the OS space and change its contents. However, since the OS is not protected, it is impossible to prevent the contents of the OS and the like from being destroyed when the program runs away. Therefore, there is a disadvantage that the operation of the OS or the like cannot be guaranteed.

A method that supports the space management function of the OS, that is, a method that performs exactly the same processing as the space management function of the OS and performs address translation when the contents of the OS must be changed for debugging or the like.

With the same space management function as this OS, the OS can search the address management table set in the PMMU 12 for space management with the same software as the PMMU 12 does, and find the physical address corresponding to the logical address to be searched. it can.

This method can preserve the protection functions of the OS and the like, but on the other hand, it complicates functions and processing for changing the contents of the OS, resulting in poor processing efficiency and inconvenient development.

[Problems to be solved by the invention]

A conventional debugging system for changing the contents of a write-protected space of an OS using a PMMU that does not have a write protection release function dynamically has the above-mentioned method. However, the former does not use the write protection function of the PMMU, so the contents of the OS are destroyed and its operation cannot be guaranteed.The latter has a complicated function and process for changing the contents. There was a problem that it led to duplication of development.

The present invention provides a write-protection function that allows a write-protected space on a physical memory to be accessed and its contents changed or referred to while retaining a write-protection function and without providing a special space management function. An object of the present invention is to provide a debugging system for changing the contents of a space.

[Means for solving the problem]

Since PMMU12 does not have a write protection release function dynamically, even if debugging etc. is accessed with privileged execution qualification,
When the instruction of the program is a change of the contents of the OS, the writing to the OS space is prohibited by invalidating the instruction. However, if the user has the privilege to execute the privilege, at least the address conversion, that is, the processing up to obtaining the physical address corresponding to the logical address is performed. The present invention focuses on the address conversion function of the PMMU 12, and temporarily disables the operation of the PMMU 12 at the stage when the physical address corresponding to the logical address to be converted is obtained, and accesses the OS space on the physical memory by using this physical address. It makes necessary changes and references.

Hereinafter, the solution means adopted by the present invention will be described with reference to FIG. FIG. 1 is a flowchart showing the basic configuration of the present invention.

In FIG. 1, in the process S _1, the process for obtaining the physical address corresponding to the conversion target logical address by the address conversion function of the PMMU12 is performed.

In the process S _2, to temporarily disable operation of PMMU12 After the physical address is Motoma' in the process S _1, the process of accessing a predetermined write-protected space in physical memory is performed by the physical address.

(Operation)

The operation of the present invention will be described by taking as an example a case where a test or maintenance of an OS or the like is performed and a bug is found and the content of the OS space needs to be changed. The processing is
This is performed by the computer system shown in FIG.

A debug request command (execution qualification is privileged) is issued by a debugger (not shown), and when the command is accepted by the MPU 11, the logical address to be converted is input to the PMMU 12. PMMU12
Performs address translation by its address translation function,
A process for obtaining a physical address corresponding to the logical address to be converted is performed (process S ₁ ).

This address conversion process is performed, for example, by referring to an address management table in which the OS associates the logical address and the physical address set in the PMMU 12 (details will be described in the section of the embodiment).

When the physical address corresponding to the logical address to be converted is obtained, the MPU 11 invalidates the operation of the PMMU 12 once. As a result, the write protection of the PMMU 12 does not function, so that the debug accesses the physical memory, that is, the main memory 13 with the requested physical address and changes the contents (debug).
I do. In addition, the contents are referred to as needed.

When the processing such as the predetermined change is completed, the MPU 11 releases the invalidation of the PMMU 12 and returns to the original state having the write protection function.

As described above, the physical address corresponding to the logical address to be converted is obtained by using the address conversion function without impairing the write protection function of the PMMU 12, and the physical address on the physical memory is not provided without providing a special space management function. The user can access the write-protected space and change or refer to the contents. In this case, the user can access the OS space with the privileged execution qualification without being aware of the write protection function of the PMMU 12.

〔Example〕

An embodiment of the present invention will be described with reference to FIGS. FIG. 2 is a flowchart showing the processing of one embodiment of the present invention, FIG. 3 is a block diagram showing the configuration of an address management table, and FIG. 4 is a page descriptor and a pointer disk. It is explanatory drawing of each format of a lip. The computer system shown in FIG. 5 is used as an embodiment system of the embodiment of the present invention, and its hardware configuration is as described above.

(A) Configuration of Memory Management Table First, the configuration of the memory management table will be described with reference to FIG.

In FIG. 3, reference numeral 40 denotes a memory management table, which is set in the PMMU 12 by the OS. 32 is the physical memory space described above.

41 (41A to 41D) are page tables, and each table is provided with a page descriptor for managing each logical address to be converted. In each page descriptor, a physical address corresponding to the logical address to be converted is set.

FIG. 4A shows a format example of the page descriptor. (A) of FIG. 7A shows the format of the page descriptor in the short format, and (b) of FIG. 7A shows the format of the long format.

The short format has a 1-word configuration, and the upper stage (16 bits)
And the lower stage (16 bits). The upper 16 bits and the lower 15 to 8 bits are a page address field which stores a physical address corresponding to the logical address to be converted.

Various format information is stored in the G, CL, L, M, U, WP, and DT fields stored in the lower 0 to 8 bits. Of these, the 2-bit DT field has a page
“01” indicating a descriptor is stored.
The description of the meanings of the other symbols is omitted.

The long format consists of two words, with each word in the upper row (16
Bit) and the lower stage (16 bits). The upper 16 bits (31 to 16 bits) of the first word are unused, and various format information is stored in the lower 16 bits (16 to 0 bits). As with the short type,
"01" indicating a page descriptor is stored in the 2-bit DT field. The upper 16 bits and the lower 15 to 4 bits are a page address field which stores a physical address corresponding to the address to be converted. The lower 0 to 3 bits are unused areas.

In both the short format and the long format, information indicating that the format is the short format or the long format is not stored in the format information. ) Is stored in the DT field of the format information of the above pointer descriptor.

Reference numeral 42 denotes a route pointer, which points at addresses in the respective logical spaces of the supervisor code, supervisor data, user code, and user data. Each code (program) and data of the supervisor and the user are scattered in the physical space, but when managing, the code and data are arranged so as to be continuous in the logical space for each supervisor and user as shown in the figure. Be managed.

Reference numeral 43A denotes a pointer table A for the supervisor code and the supervisor data, which is composed of a page descriptor pointing to the logical address to be converted and a multi-level (hierarchical) pointer descriptor pointing to the address of the page descriptor.

FIG. 4B shows a format example of the pointer descriptor. (A) of FIG. 7B is a short type, and (b) of FIG. 8B is a long type.

The short format has a 1-word configuration, and the upper stage (16 bits)
And the lower stage (16 bits). The upper stage 16 bits store the upper 31 to 16 bits of the table address PA of the table of the next hierarchy (level), and the lower stage 15 to 4 bits store the table address. The lower 15 to 4 bits of PA are stored. Various format information is stored in the lower 0 to 4 bits, and a 2-bit DT field includes a descriptor (pointer descriptor or page descriptor) of the next hierarchy (level) pointed to by the pointer descriptor. "10" indicating that the format is short-circuit formation is stored.

The long format consists of two words, with each word in the upper row (16
Bit) and the lower stage (16 bits). The upper 16 bits (31 to 16 bits) of the first word are unused,
Various format information is stored in the lower 16 bits (16-0 bits). In the 2-bit DT field, “11” indicating that the format of the descriptor of the next hierarchy (level) is the long format is stored. In the upper 16 bits (31 to 16 bits) of the second word, the upper 31 to 16 bits of the table address PA which is the address of the table of the next hierarchy (level) are stored.
In the 16 to 4 bits, the lower 15 to 4 bits of the table address PA are stored. Bits 0 to 3 in the lower stage are unused.

In both the short format and the long format, as in the case of the page descriptor, information indicating whether the format is the short format or the long format is stored in the format information. Instead, it is stored in the DT field of the format information of the pointer descriptor one level higher.

Reference numeral 43B in FIG. 3 is a pointer table for the user code and the user data. The structure of the page descriptor and the pointer descriptor for the user code and the user data is the same as the page descriptor and the pointer descriptor for the supervisor code and the data. (See FIG. 4).

(B) Operation of the Example The operation of the present invention will be described in accordance with the processing steps in FIG. 2 in a case where a bug is found by testing or maintaining the OS or the like and the contents of the OS space are changed by debugging. I do. The processing S ₁ and S ₂ of Figure 2, is as described in Figure 1, the process S ₁₁ to S ₁₅ is a specific internal processing of the processing S _1. The processing of this embodiment is performed by the computer system shown in FIG.

Processing S _{11 When a} debug request command (execution qualification is privileged) is issued from a debug (not shown) and accepted by the MPU 11, the logical address to be converted is changed from the debug to the external bus 15.
Through to PMMU12.

The MPU 11 selects one logical space by the route pointer 42 because it is unknown in which logical space the supervisory address, the supervisor data, the user code, and the user data exist. MPU1
1 indicates that the root pointer 42 selects a logical space in the order of supervisor code → supervisor data → user code → user data, but first the logical space of the supervisor code is selected.

When the process S _12, S ₁₃ logical space of supervisor code is selected, MPU 1
1 issues a search instruction (hereinafter, referred to as a ptest instruction) to the PMMU _12, and performs processing for obtaining the address of a page descriptor pointing to the logical address to be converted (processing S12).

As described with reference to FIG. 4, each page descriptor is sequentially searched by pointing the pointer descriptor of the pointer table 43A from the upper hierarchy to the lower hierarchy by the ptest instruction, and the logical address to be converted is determined. The presence or absence of the address of the page descriptor to be pointed is searched.

If, when the page descriptor that points to the converted logical address in the logical space of the supervisor code is not found, the processing returns to S ₁₁ (processing S _13).

The MPU 11 selects the next logical space (supervisor data) by the route pointer 42 and ptes to the PMMU 12
The t instruction is issued to perform processing for obtaining the address of the page descriptor that points to the logical address to be converted in the logical space of the supervisor data. When the desired page descriptor is not searched in the logical space of the supervisor data, the above-described S is performed for each logical space of the user code and the user data in the same manner.
_{Steps 11} and ₁₂ are performed.

When a page descriptor that points to the process S ₁₄ converted logical address is determined, in order to know the page address storage location in the page descriptor, the page descriptor format short format or long form of seeking final pointer descriptor It is necessary to perform a process of knowing whether or not this is the case (see the description of FIG. 4 in the section (A)).

Therefore, first, when the page descriptor is obtained, the hierarchy (level) of the existence of the table is obtained.

Process S _{15 The} MPU 11 ptests the table one level higher than the obtained level
Find again by instruction. As a result, the final pointer descriptor pointing to the page descriptor is obtained, and by detecting whether the DT field in the format information is “10” or “11”, the format of the page descriptor is short-circuited. ("10") Long format ("11")
(See the description of FIG. 4).

According to the process S ₁₆ Motoma' form, obtaining the physical address conversion target logical address that is set in the page descriptor corresponds. That is, as described with reference to FIG. 4A, in the short format, the physical address corresponding to the logical address to be converted is set in the 8- to 31-bit page address field.
A physical address corresponding to the logical address to be converted is set in the page address field of up to 31 bits.
The actual physical address is the same as the normal calculation method for obtaining the physical address from the logical address, and the remaining lower bits (both short and long formats) of the physical address obtained from the page address field of the page descriptor are 0 to 0.
7 bits, see FIG. 4) to which the lower bits corresponding to the logical address to be converted are assigned.

When the physical address corresponding to the logical address to be converted is obtained, the MPU 11 temporarily disables the operation of the PMMU 12 to release the write protection function, and debugs that the physical memory, that is, the MSU 13 is writable, and debugs the obtained physical address. Notify the side. For debugging, the MSU 13 is accessed at the notified physical address, the OS space is written, the contents are changed, and necessary debugging is performed.

When the content change processing or the like is completed, the MPU 11 releases the operation invalid state of the PMMU 12, and returns to the state having the original write protection function.

As described above, it is possible to access the OS space, which is usually a write-protected space, at the time of debugging and make necessary changes.

〔The invention's effect〕

As described above, according to the present invention, the following effects can be obtained.

(1) While retaining the write protection function, it is possible to access the write-protected space on the physical memory and to refer to or change the contents without providing a special space management function.

(2) The user can access the OS space with the privileged execution qualification and refer to or change the contents without being aware of the write protection function of the memory management coprocessor.

[Brief description of the drawings]

FIG. 1 is an explanatory diagram of a basic configuration of the present invention, FIG. 2 is a processing flowchart of an embodiment of the present invention, FIG. 3 is an explanatory diagram of an address management table used in the embodiment, FIG. Is an explanatory diagram of each format of a page descriptor and a pointer descriptor of the address management table, FIG. 5 is an explanatory diagram of a configuration of a computer system including a memory management coprocessor, and FIG. FIG. 7 is an explanatory diagram of a memory map of a logical space of the system. FIG. 7 is an explanatory diagram of a correspondence between a logical space and a physical space. 3 and 5, 10 ... CPU board, 11 ... Instruction processor (MPU), 12 ...
... Memory management co-processor (PMMU), 13 ... Main storage unit (MSU), 14 ... Internal bus, 15 ... External bus, 40 ...
... Memory management table, 41 ... Page table, 42 ...
... Root pointer, 43A, 43B ... Pointer table.

Claims (2)

(57) [Claims] 1. A debug system for dynamically changing the contents of a space in an operating system using a memory management coprocessor without a write protection release function, comprising the steps of: Issuing means for issuing a request, a memory management coprocessor for protecting a change to the contents of the space and converting a logical address to be accessed by the issuing means into a physical address, and And a rewriting means for rewriting the contents of the space based on the physical address after the invalidation. 2. The debugging system according to claim 1, wherein said rewriting means includes reference to the contents of said space based on said physical address.