US20050235277A1 - Automatic gopher program generator - Google Patents

Automatic gopher program generator Download PDF

Info

Publication number
US20050235277A1
US20050235277A1 US11/158,250 US15825005A US2005235277A1 US 20050235277 A1 US20050235277 A1 US 20050235277A1 US 15825005 A US15825005 A US 15825005A US 2005235277 A1 US2005235277 A1 US 2005235277A1
Authority
US
United States
Prior art keywords
field
gopher
defined instruction
size
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/158,250
Inventor
Andrew McDermott
Christopher Cherrington
Alister Roberts
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wind River Systems Inc
Original Assignee
Wind River Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wind River Systems Inc filed Critical Wind River Systems Inc
Priority to US11/158,250 priority Critical patent/US20050235277A1/en
Publication of US20050235277A1 publication Critical patent/US20050235277A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design

Definitions

  • Computer systems typically include software (computer programs) and hardware (the physical components), such as a central processing unit (CPU) that stores and executes software, a monitor to display output and a keyboard and mouse to accept input commands from a user, as a simple example.
  • Complex systems include thousands of computer systems connected by a network with mass storage devices and any number of peripherals, i.e., printers, scanners, back-up systems, modems.
  • An operating system is a collection of system programs that allow users to run application software, such as word processors, spreadsheet programs and e-mail software on a specific set of hardware, or platform.
  • the operating system acts as an interface between hardware, the users, and software by abstracting the real hardware of the system to present a virtual machine.
  • the core of an operating system is generally referred to as its ‘kernel’, a software module that manages interaction between and among hardware and software components, resource allocation and memory access and storage.
  • the development usually occurs on a “host” system, separate from the intended “target” system, in an integrated development environment (IDE).
  • IDE integrated development environment
  • the environment includes a number of software tools, each with a specific functionality useful for development of the application.
  • the host system needs information about the state and condition of various aspects of the target system. For example, the host system may need information regarding the type and internal state of a message queue which contains messages from system components reflecting the state of the system.
  • Target state information may be retrieved by reading data stored in kernel objects on the target.
  • a gopher program is one method used to retrieve information from a kernel object by accessing a specific part of a kernel object, retrieving the information stored in that part, and returning the results in a data stream which is commonly referred to in the art as a “tape”.
  • An example of an IDE that uses gopher programs is the Tornado® Development Environment by Wind River Systems, Inc. of Alameda, Calif.
  • the Tornado® Inspector is a software tool within the environment that allows the user to browse a variety of target system kernel objects by sending gopher programs to the target to extract and return certain information in a tape, or stream of data. For each kernel object that can be inspected a corresponding gopher program needs to be written.
  • a system and method for automatically generating a gopher program invokes a debugger and loads a type library into the debugger.
  • the type library contains information regarding each data type required to retrieve desired state information from a target computing environment.
  • the system reads each line of a command file, wherein the command file is comprised of literal text and one or more predefined instructions. For each predefined instruction read, the system calls a corresponding function in the debugger and the debugger returns a numerical offset value based upon information in the type library.
  • the system copies each line of the command file to an output file, with each predefined instruction replaced with its corresponding offset value.
  • a method for automatically generating gopher programs is provided in accordance with an embodiment of the present invention.
  • the plurality of data types include primitive data types and compound data types.
  • the type library binary image is fed to the debugger.
  • An input command file with pre-defined instructions, e.g., a command or macro, and literal text is parsed. As the file is parsed, the pre-defined instructions are identified and a corresponding function in the debugger is called to retrieve a field size and a field position from the type library binary image to calculate a specific offset value of a field in one of the compound data types.
  • the specific offset value is substituted for the pre-defined instruction in the input command file to produce a gopher program with the literal text and the specific offset value.
  • a gopher program generator is provided in accordance with another embodiment of the present invention.
  • the generator comprises a type library binary image, an input command file, a set of pre-defined instructions, and a script.
  • a debugger is provided with a set of functions, where each of the functions corresponds to one of the pre-defined instructions.
  • the script which implements the generator, is constructed and arranged to compile with debug information to produce the type library binary image, feed the image to the debugger and parse the input command file for one of the pre-defined instructions in the set.
  • the type library binary image includes information regarding each data type of interest. It should be noted that the input command file includes other data, literal text, besides the pre-defined instructions that is not modified.
  • a pre-defined instruction When a pre-defined instruction is identified, its corresponding function is called to retrieve a field size and a field position from the type library binary image to calculate a specific offset value of a field in a compound data type.
  • the specific offset value is substituted for the pre-defined instruction in the input command file to produce a gopher program that includes the literal text and the specific offset value substituted for the pre-defined instruction.
  • a system for generating gopher programs comprising a processor and a data storage device operably connected to the processor, the data storage device including a program executable by the processor to execute the steps of the method of the present invention.
  • computer readable media which have stored thereon computer executable process steps operable to control a computer to implement the method described above.
  • FIG. 1 shows a graphical representation of a microchip and data stored thereon.
  • FIG. 2 shows the interaction of the components in a gopher generator according to an embodiment of the present invention.
  • FIG. 3 is a flowchart for the process of a gopher generator according to an embodiment of the present invention.
  • a method for creating a gopher program includes the steps of reading and parsing a command file.
  • the command file includes a mixture of literal text and predefined instructions (commands).
  • a debugger Prior to parsing the command file, a debugger is started and a type library is loaded.
  • This type library contains information about the size and structure of all data types to be used.
  • Primitive data types are defined by the particular programming language, for example, “int” and “char” types in C.
  • Compound data types are user-defined, e.g., data structures in the programming language C, and include primitive data types and sometimes, other compound data types.
  • literal text is copied directly to the output gopher program.
  • a corresponding function in the debugger will be called which will return an appropriate numerical value based upon the information in the type library. This numerical value will be copied to the output gopher program in place of the predefined instruction.
  • the mechanism for reading arbitrary data structures in the Tornado environment is the WTX (Wind Tool Exchange) Application Programming Interface (API), and specifically a C function (for example) entitled ‘wtxGopherEval( )’.
  • WTX Wind Tool Exchange
  • API Application Programming Interface
  • C function for example
  • This function accepts a gopher program and forwards it to the target system for execution.
  • the function also returns the gopher results in a “tape” (i.e., data stream).
  • the data structure in Table 1 is an object from which information is to be retrieved via wtxGopherEval( ).
  • the object of Table 1 is entitled “msg_q” and defined as type “struct” (in C, a user-defined data structure) in the first and second lines.
  • the fields of the data structure are defined first with their type, “int” (integer) and then names, e.g., options, maxMsgs, maxMsgLength, etc.
  • the fields are examples of primitive data types and the data structure, which is user-defined, is an example of a compound data type that includes not only primitive types, but compound types as well (the “msg_q” variable) TABLE 1 Data structure.
  • FIG. 1 shows a graphical representation of a memory, generally indicated by reference numeral 10 .
  • This particular memory 10 includes storage locations 12 , each comprising eight storage cells 14 .
  • Each cell 14 holds one bit of information, i.e., a “1” or “0”, and each location holds eight bits, referred to as one byte.
  • Each location 12 has an address 16 for access and retrieval of the information stored therein.
  • Each field within a compound data type such as a data structure has a certain size, determined by the processor and compiler used. For example, the size of an “int” (integer) field on a Intel Pentium® X86 processor would be 4 bytes when its data structure is designed and implemented in the C programming language and compiled with the Gnu compiler. Changing the compile would change the storage size for the data structure fields, even if the same processor were used. The reverse is true as well, changing the processor while using the same compiler changes the storage sizes for the data fields.
  • Table 3 shows the different offsets that would result in compiling the same data structure for a MIPS processor. Even though the integer fields are the same size as they are on the Intel processor, the first field, “*next,” a pointer to a defined type, is eight bytes long. Because the “*next” field is first, it shifts all the remaining offsets for the integer fields even though the size of the integer fields remain the same. TABLE 3 Data structure offsets on a different processor.
  • maximum Msgs the maximum number of messages in a MSG_Q object—is being retrieved from the data object using a gopher program.
  • the field, “max Msgs,” is offset from the beginning of this structure by eight address locations.
  • To construct a gopher program to retrieve the “maxMsgs” field we need to construct a gopher program that would initialize the gopher pointer to the beginning of this structure, advance the pointer by eight locations to the beginning of the “maxMsgs” field and then write the next four locations into the tape.
  • Such a gopher program could be implemented as follows:
  • MSG_Qaddr is a pointer that loads the address location at the beginning of the MSG_Q data structure into the gopher pointer.
  • ⁇ +8@> is a gopher program comprised of gopher commands that advance the pointer eight locations to the beginning of the “maxMsgs” field (“+8”) and writes 4 bytes (“@”) to the tape.
  • the term “gopher program” refers to the gopher commands' exclusive of any initial pointer.
  • the gopher result tape is a byte-packed data stream formatted as a series of pairs, each pair with a type code and its associated data. Assuming the value of maxMsgs is 128, the above gopher program would return the following values in the tape: “0 128” where 128 is the value of that particular “maxMsgs” field and 0 is the gopher type identifier which in this case refers to the integer type.
  • MSG_Q data structure changes, however, then its corresponding gopher programs would be invalidated and have to be recalculated. Changes to the data structure include adding new fields or changing their type.
  • the gopher-program yields incorrect results.
  • the size of the fields do not change, they are all four bytes, however, adding the “*prev” field at the beginning of the data structure shifts all the following fields by four bytes from those values in Table 2.
  • maxMsgs its offset in Table 2 is +8 where, in Table 4, it is +12. Therefore, the previous gopher program, “MSG_Q addr ⁇ +8@>,” would not extract the value of maxMsgs. Rather, the value of the field eight address locations (+8) after the beginning of the data structure address would be returned.
  • the generation of gopher programs outlined above is automated by extracting type information to calculate offsets so that each time there is a change in a compound data type (e.g., a data structure), the new offset is automatically substituted into the gopher program.
  • a compound data type e.g., a data structure
  • the compiled binary image (in 0's and 1's) of a program when compiled with debug information, includes the field types used in the program with their specifications, such as storage size. Therefore, it is possible to access run-time type information for a binary image without actually running the program.
  • a program is compiled and its debugging information is included in the object file, it can be accessed to determine the types of the defined fields in the program's data structures without actually executing the program.
  • other platform specification information such as the type of compiler and processor, is determined. From the type information and platform specifications, field sizes can be ascertained and the corresponding offsets for data structure fields can be calculated to create the appropriate gopher program.
  • a “type library” is created including all the data types involved so that the necessary type information is available to calculate the correct offsets. For example, consider the following configuration, assuming that only two types, the integer and character primitive data types, will be used. In the Tornado® development environment with a target system running on a VxWorks® platform, an operating system distributed by Wind River Systems, Inc., the type library could be as simple as:
  • the C programming language is used to code the type library; debugging is accomplished using a Gnu debugger; and a Perl script implements the gopher generator.
  • the gopher generator Perl script
  • the generator sends function calls to the Gnu debugger to evaluate certain pre-defined instructions, or gopher generator commands, such as:
  • the debugger executes the functions, which examine the type library binary image to determine the size of a field and to determine a field position, and returns both to the generator script. These values are used to calculate the offset of a field within a structure (offset_of), the size of a particular type (sizeof), and the C array size of a global variable (array_size). Other gopher generator commands can also be implemented if desired.
  • the debug information may be included in the compiled image a number of ways, depending on the compiler used. For example, in the above configuration using the Gnu compiler, a “-g” switch is provided for such functionality.
  • the text file is read on a line by line basis and each line is scanned for the gopher generator commands: “offset_of”, “sizeof”, “array_size” outlined above.
  • the gopher generator calls a corresponding function in the debugger. The debugger then executes the corresponding function and if successfully executed, the results are substituted in the input line. If the function fails, a fatal error is signaled in the input line and the gopher generator exits with an error.
  • the function By examining the binary image of the data structure in the type library binary image, the function ascertains that maxMsgs is an integer type, determines the configuration of the MSG_Q data structure, accesses the type information in the compiled binary image of the type library binary image to -determine the offsets of each variable in the MSQ_Q data structure, calculates the offset of maxMsgs, and returns the calculated offset value to the generator which then substitutes the offset value to yield the following line in the input command file:
  • the gopher generator substitutes those gopher generator commands that it recognizes on a line by line basis. This allows the gopher generator to be extended to accommodate new gopher generator commands as and when they become necessary. For example, if an input line contained the following:
  • the generator replaces certain specified text, namely, the gopher generator commands, with the appropriate value (e.g., offset value, size value, array size value).
  • the appropriate value e.g., offset value, size value, array size value.
  • a gopher generator command included a member that did not exist, for example:
  • the input text file is preferably preprocessed by the pre-processor.
  • This mechanism allows one file to include another.
  • the MSG_Q data type could be described in its own file. This could then be included by other files that would need access to MSG_Q members.
  • This mechanism promotes the development of a type library.
  • the MSG_Q data structure could be stored in it's own file: “MSG_Q.gp”, and from another text file we could simply include it with “#include “MSG_Q.gp.”
  • FIG. 2 shows the interaction of the components of the system according to an embodiment of the present invention.
  • the automatic gopher generator 20 accepts a command file 22 as input.
  • the binary image of the type library 21 is fed to the debugger 24 .
  • the text file 22 is parsed for pre-defined gopher generator commands, and if found, the appropriate function call 27 is sent to the debugger 24 which, returns a value 25 that is substituted into the gopher generator command's corresponding position in the text file to produce a gopher program 26 .
  • the text file can then be saved under an appropriate file name or printed.
  • the process of the gopher program generator is shown in the flowchart of FIG. 3 .
  • the generator starts (step 30 ) by launching the debugging process (step 32 ) and feeding the type library binary image to the debugger (step 34 ).
  • the generator then parses the command file line by line (step 36 ). After parsing a line of the input command file, the generator checks to see if it is at the end of the file (step 37 ). If so, then the generator returns the output (a gopher program) at step 38 . Otherwise, if the generator is not at the end of the text file (step 37 ), the next step determines if one of the pre-defined gopher generator commands is present in the line (step 39 ).
  • step 46 the generator goes to the next line (step 46 ) and repeats parsing for the EOF (step 37 ) and pre-defined gopher generator commands (step 39 ) until either the EOF or a gopher generator command is found.
  • step 40 Once a gopher generator command is found, its corresponding function is called (step 40 ).
  • the function returns its result (step 42 ) and the generator determines if the returned result is an error (step 43 ). If an error is returned, the generator terminates (step 38 ). If there is a value returned (step 43 ), it is substituted in the place of the gopher generator command text (step 44 ).
  • the generator then goes to the next line (step 46 ) and continues to parse the remainder of the input command file (step 36 ).
  • an employee.p command file contains the following: TABLE 7 CommandFile ! ⁇ +offsetOf(employee_struct.id)@> ⁇ +offsetOf(employee_struct.firstname)*$> ⁇ +offsetOf(employee_struct.lastname)*$>
  • the gopher program is invoked via the command line:
  • the gopher generator reads the contents of the now fully pre-processed command file line-by-line while looking for gopher generator commands.
  • the only command used is “offsetOf”, which computes the offset of the given field.
  • each command in this case, gopher generator commands
  • the input command file is followed by an open parentheses “(”, and the end of the command with a close parentheses “)”.
  • the contents between the “(” and the “)” are the command's parameter.
  • each command can take a variable number of parameters, including none.
  • the input line contains a gopher generator command, then it is transformed according to that command. Taking the lines of “employee.p” one by one, the results are as follows.
  • the first input line is:
  • the next input line is:
  • the final output line is:
  • the gopher generator Since there are no more input lines from the command file, the gopher generator outputs (in this example, prints to a file or printer via the print-gp.pl command) a gopher program suitable for a gopherEval ( ) via WTX.
  • the gopher program is the result of combining the input lines.
  • the generated gopher program is:
  • a gopher program is used in conjunction with an initial pointer.
  • a pointer to the beginning the employee_struct data structure on the target would be identified by the user (e.g., from a symbol table), and the pointer plus the above gopher program would be sent to the target via WTX.

Abstract

A system and method for automatically generating a gopher program is provided. The system invokes a debugger and loads a type library into the debugger. The type library containing information regarding each data type used in a program. The system reads each line of a command file, wherein the command file is comprised of literal text and one or more predefined instructions. For each predefined instruction read, the system calls a corresponding function in the debugger and the debugger returns a numerical offset value based upon information in the type library. The system copies the each line of the command file to an output file, with each predefined instruction replaced with its corresponding offset value.

Description

    BACKGROUND
  • Computer systems typically include software (computer programs) and hardware (the physical components), such as a central processing unit (CPU) that stores and executes software, a monitor to display output and a keyboard and mouse to accept input commands from a user, as a simple example. Complex systems include thousands of computer systems connected by a network with mass storage devices and any number of peripherals, i.e., printers, scanners, back-up systems, modems.
  • An operating system is a collection of system programs that allow users to run application software, such as word processors, spreadsheet programs and e-mail software on a specific set of hardware, or platform. The operating system acts as an interface between hardware, the users, and software by abstracting the real hardware of the system to present a virtual machine. The core of an operating system is generally referred to as its ‘kernel’, a software module that manages interaction between and among hardware and software components, resource allocation and memory access and storage.
  • When developing software applications for computer systems with minimal resources and I/O capabilities, the development usually occurs on a “host” system, separate from the intended “target” system, in an integrated development environment (IDE). The environment includes a number of software tools, each with a specific functionality useful for development of the application. Often during the development process, the host system needs information about the state and condition of various aspects of the target system. For example, the host system may need information regarding the type and internal state of a message queue which contains messages from system components reflecting the state of the system.
  • Target state information may be retrieved by reading data stored in kernel objects on the target. A gopher program is one method used to retrieve information from a kernel object by accessing a specific part of a kernel object, retrieving the information stored in that part, and returning the results in a data stream which is commonly referred to in the art as a “tape”. An example of an IDE that uses gopher programs is the Tornado® Development Environment by Wind River Systems, Inc. of Alameda, Calif.
  • The Tornado® Inspector is a software tool within the environment that allows the user to browse a variety of target system kernel objects by sending gopher programs to the target to extract and return certain information in a tape, or stream of data. For each kernel object that can be inspected a corresponding gopher program needs to be written.
  • SUMMARY
  • A system and method for automatically generating a gopher program is provided. The system invokes a debugger and loads a type library into the debugger. The type library contains information regarding each data type required to retrieve desired state information from a target computing environment. The system reads each line of a command file, wherein the command file is comprised of literal text and one or more predefined instructions. For each predefined instruction read, the system calls a corresponding function in the debugger and the debugger returns a numerical offset value based upon information in the type library. The system copies each line of the command file to an output file, with each predefined instruction replaced with its corresponding offset value.
  • A method for automatically generating gopher programs is provided in accordance with an embodiment of the present invention. A type library with information on the size and structure of a plurality of data types compiled with debug information to produce a type library binary image. The plurality of data types include primitive data types and compound data types. The type library binary image is fed to the debugger. An input command file with pre-defined instructions, e.g., a command or macro, and literal text is parsed. As the file is parsed, the pre-defined instructions are identified and a corresponding function in the debugger is called to retrieve a field size and a field position from the type library binary image to calculate a specific offset value of a field in one of the compound data types. The specific offset value is substituted for the pre-defined instruction in the input command file to produce a gopher program with the literal text and the specific offset value.
  • A gopher program generator is provided in accordance with another embodiment of the present invention. The generator comprises a type library binary image, an input command file, a set of pre-defined instructions, and a script. A debugger is provided with a set of functions, where each of the functions corresponds to one of the pre-defined instructions. The script, which implements the generator, is constructed and arranged to compile with debug information to produce the type library binary image, feed the image to the debugger and parse the input command file for one of the pre-defined instructions in the set. The type library binary image includes information regarding each data type of interest. It should be noted that the input command file includes other data, literal text, besides the pre-defined instructions that is not modified. When a pre-defined instruction is identified, its corresponding function is called to retrieve a field size and a field position from the type library binary image to calculate a specific offset value of a field in a compound data type. The specific offset value is substituted for the pre-defined instruction in the input command file to produce a gopher program that includes the literal text and the specific offset value substituted for the pre-defined instruction.
  • A system for generating gopher programs is also disclosed comprising a processor and a data storage device operably connected to the processor, the data storage device including a program executable by the processor to execute the steps of the method of the present invention.
  • In accordance with other embodiments of the present invention, computer readable media are provided which have stored thereon computer executable process steps operable to control a computer to implement the method described above.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a graphical representation of a microchip and data stored thereon.
  • FIG. 2 shows the interaction of the components in a gopher generator according to an embodiment of the present invention.
  • FIG. 3 is a flowchart for the process of a gopher generator according to an embodiment of the present invention.
  • DETAILED DESCRIPTION
  • For purposes of this detailed description, familiarity with the gopher scripting language as implemented in the Tornado® IDE is presumed. Detailed discussion of the gopher language is provided in Tornado® 2.0 API Programmer's Guide, available from Wind River Systems, and in WIPO publication no.: WO 98/09208, the contents of which are expressly incorporated herein by reference.
  • Manually generating a gopher program to extract data from a kernel is both time consuming and error-prone. It also requires a deep understanding of both the host toolchain and target architectures. Any change that affects kernel data structures requires existing gopher programs to be reviewed. If any part of a gopher program needs modification, the entire program must be re-created.
  • A method for creating a gopher program is provided in accordance with an embodiment of the present invention. The method includes the steps of reading and parsing a command file. The command file includes a mixture of literal text and predefined instructions (commands). Prior to parsing the command file, a debugger is started and a type library is loaded. This type library contains information about the size and structure of all data types to be used. Generally, there are two kinds of data types, primitive data types and compound data types. Primitive data types are defined by the particular programming language, for example, “int” and “char” types in C. Compound data types are user-defined, e.g., data structures in the programming language C, and include primitive data types and sometimes, other compound data types. As the parser reads the command file, literal text is copied directly to the output gopher program. For each predefined instruction encountered, a corresponding function in the debugger will be called which will return an appropriate numerical value based upon the information in the type library. This numerical value will be copied to the output gopher program in place of the predefined instruction.
  • An exemplary implementation of the system and method according to an embodiment of the present invention is presented herein as it would operate in the Tornado® IDE. It should be noted that the principles and concepts disclosed herein may be applied to the use of gopher programs on any platform.
  • The mechanism for reading arbitrary data structures in the Tornado environment is the WTX (Wind Tool Exchange) Application Programming Interface (API), and specifically a C function (for example) entitled ‘wtxGopherEval( )’. This function accepts a gopher program and forwards it to the target system for execution. The function also returns the gopher results in a “tape” (i.e., data stream).
  • As an example, assume the data structure in Table 1 is an object from which information is to be retrieved via wtxGopherEval( ). The object of Table 1 is entitled “msg_q” and defined as type “struct” (in C, a user-defined data structure) in the first and second lines. In the lines that follow, the fields of the data structure are defined first with their type, “int” (integer) and then names, e.g., options, maxMsgs, maxMsgLength, etc. The fields are examples of primitive data types and the data structure, which is user-defined, is an example of a compound data type that includes not only primitive types, but compound types as well (the “msg_q” variable)
    TABLE 1
    Data structure.
    typedef struct msg_q /* MSG_Q */
     {
     struct msg_q *next; /* next message */
     int options; /* message queue options */
     int maxMsgs; /* max number of messages
    in queue */
     int maxMsgLength; /* max length of message */
     int maxMsgsQueued; /* max number of messages
    queued */
     int sendTimeouts; /* number of send timeouts */
     int recvTimeouts; /* number of receive timeouts */
     } MSG_Q;
  • To construct a gopher program for retrieving information from the object of Table 1, it is first necessary to identify which fields information will be extracted from. If, for example, the program were to return the maximum number of messages in the MSG_Q object, the gopher program would be designed to access and retrieve the value in the field “maxMsgs”.
  • To understand how gopher programs retrieve information, a simple explanation of how information is stored in computer memory is appropriate. Computers store information in digital form, i.e., ones (1) and zeroes (0). FIG. 1 shows a graphical representation of a memory, generally indicated by reference numeral 10. This particular memory 10 includes storage locations 12, each comprising eight storage cells 14. Each cell 14 holds one bit of information, i.e., a “1” or “0”, and each location holds eight bits, referred to as one byte. Each location 12 has an address 16 for access and retrieval of the information stored therein.
  • When computer software is created, it is first written in a programming language. The completed program is converted, or compiled, into a language that computers understand. When compiled, programs are also checked for mistakes and faults (bugs) so they can be removed. This process is known as debugging.
  • Each field within a compound data type such as a data structure has a certain size, determined by the processor and compiler used. For example, the size of an “int” (integer) field on a Intel Pentium® X86 processor would be 4 bytes when its data structure is designed and implemented in the C programming language and compiled with the Gnu compiler. Changing the compile would change the storage size for the data structure fields, even if the same processor were used. The reverse is true as well, changing the processor while using the same compiler changes the storage sizes for the data fields.
  • Assuming the above configuration of processor (Intel x86) and compiler (Gnu) for the data structure in Table 1, each field is four bytes long, taking up four storage locations. Therefore, the first line of the data structure is the beginning of the data structure in memory. Because “*next” is four bytes long (recognized as a pointer), the next field in the data structure, “options”, will be at four bytes after “*next.” Put another way, “options” will be stored at the address of “*next” plus an offset equal to the size of “*next”. Table 2 shows the offset for each field from the beginning of the MSG_Q data structure.
    TABLE 2
    Data structure with corresponding address location offsets.
    typedef struct msg_q /* MSG_Q */
    {
    +0 struct msg_q1 *next; /* next message */
    +4 int options; /* message queue options */
    +8 int maxMsgs; /* max number of messages in queue */
    +12 int maxMsgLength; /* max length of message */
    +16 int maxMsgsQueued; /* max number of messages queued */
    +20 int sendTimeouts; /* number of send timeouts */
    +24 int recvTimeouts; /* number of receive timeouts */
    } MSG_Q;
  • Table 3 shows the different offsets that would result in compiling the same data structure for a MIPS processor. Even though the integer fields are the same size as they are on the Intel processor, the first field, “*next,” a pointer to a defined type, is eight bytes long. Because the “*next” field is first, it shifts all the remaining offsets for the integer fields even though the size of the integer fields remain the same.
    TABLE 3
    Data structure offsets on a different processor.
    typedef struct msg_q /* MSG_Q */
    {
    +0 struct msg_q *next; /* next message */
    +8 int options; /* message queue options */
    +12 int maxMsgs; /* max number of messages in queue */
    +16 int maxMsgLength; /* max length of message */
    +20 int maxMsgsQueued; /* max number of messages queued */
    +24 int sendTimeouts; /* number of send timeouts */
    +28 int recvTimeouts; /* number of receive timeouts */
    } MSG_Q;
  • Data, however, is virtually never placed at the beginning of a memory starting with the first address. Therefore, a pointer is needed to point to the location where data structures begin. The pointer is the address location for the beginning of the data structure. Assume the data structure begins at address location one hundred (100). In this case, the pointer is an integer variable with the value of “100”. To access a certain field, its corresponding offset for the field is added to the pointer. Therefore, to access the “sendTimeouts” field, its offset-(+20 using Table 2) is added to the pointer (100) to obtain the address location of the start of the sendTimeouts field, 100+20=120.
  • Returning to the original example of Table 1, assume the field “maxMsgs”—the maximum number of messages in a MSG_Q object—is being retrieved from the data object using a gopher program. The field, “max Msgs,” is offset from the beginning of this structure by eight address locations. To construct a gopher program to retrieve the “maxMsgs” field we need to construct a gopher program that would initialize the gopher pointer to the beginning of this structure, advance the pointer by eight locations to the beginning of the “maxMsgs” field and then write the next four locations into the tape. Such a gopher program could be implemented as follows:
      • MSG'Q_addr<+8@>
  • “MSG_Qaddr” is a pointer that loads the address location at the beginning of the MSG_Q data structure into the gopher pointer. “<+8@>” is a gopher program comprised of gopher commands that advance the pointer eight locations to the beginning of the “maxMsgs” field (“+8”) and writes 4 bytes (“@”) to the tape. In the context of the present invention, the term “gopher program” refers to the gopher commands' exclusive of any initial pointer.
  • The gopher result tape is a byte-packed data stream formatted as a series of pairs, each pair with a type code and its associated data. Assuming the value of maxMsgs is 128, the above gopher program would return the following values in the tape: “0 128” where 128 is the value of that particular “maxMsgs” field and 0 is the gopher type identifier which in this case refers to the integer type.
  • To retrieve all values from the data structure, the following gopher program could be used:
      • MSG_Qaddr <+0@><+4@><+8@><+12@><+16@><
  • which would return:
    “0 0x12345678” *next
    “0 0” options
    “0 128” maxMsgs
    “0 12” maxMsgLength
    “0 10” maxMsgsQueued
    “0 0” sendTimeouts
    “0 0” recvTimeouts

    where the “0” is the type identifier for integer and the values are arbitrarily chosen for the fields.
  • If the MSG_Q data structure changes, however, then its corresponding gopher programs would be invalidated and have to be recalculated. Changes to the data structure include adding new fields or changing their type.
  • For example, if the MSG_Q structure is augmented with a “*prev” field, shown in Table 4, then the gopher-program yields incorrect results. The size of the fields do not change, they are all four bytes, however, adding the “*prev” field at the beginning of the data structure shifts all the following fields by four bytes from those values in Table 2. Referring to maxMsgs, its offset in Table 2 is +8 where, in Table 4, it is +12. Therefore, the previous gopher program, “MSG_Q addr <+8@>,” would not extract the value of maxMsgs. Rather, the value of the field eight address locations (+8) after the beginning of the data structure address would be returned. In the amended data structure of Table 4, the field at “MSG_Q_addr <+8@>” is “options”.
    TABLE 4
    Amended data structure.
    typedef struct msg_q /* MSG_Q */
    {
    +0 struct msg_q *next; /* next message */
    +4 struct msg_q *prev; /* prev message */
    +8 int options; /* message queue options */
    +12 int maxMsgs; /* max number of messages in queue */
    +16 int maxMsgLength; /* max length of message */
    +20 int maxMsgsQueued; /* max number of messages queued */
    +24 int sendTimeouts; /* number of send timeouts */
    +28 int recvTimeouts; /* number of receive timeouts */
    } MSG_Q;
  • Additionally, if an existing type is changed, for example, from “int” to “char”, then all the offsets will again change. Table 5 illustrates a case where “options” is a character, making its size one byte (padded to two bytes) and therefore, occupying two storage locations in memory. Again, the offsets for the following fields are shifted. It is clear that with each change of the data structure, there is a need for an entirely different gopher program.
    TABLE 5
    Data structure with changed type.
    typedef struct msg_q /* MSG_Q */
    {
    +0 struct msg_q *next; /* next message */
    +4 struct msg_q *prev; /* prev message */
    +8 char options; /* message queue options */
    +10 int maxMsgs; /* max number of messages in
    queue */
    +14 int maxMsgLength; /* max length of message */
    +18 int maxMsgsQueued; /* max number of messages
    queued */
    +22 int sendTimeouts; /* number of send timeouts */
    +26 int recvTimeouts; /* number of receive timeouts */
    } MSG_Q;
  • In accordance with an embodiment of the present invention, the generation of gopher programs outlined above is automated by extracting type information to calculate offsets so that each time there is a change in a compound data type (e.g., a data structure), the new offset is automatically substituted into the gopher program. The process is explained below.
  • The compiled binary image (in 0's and 1's) of a program (usually referred to as object code or object files), when compiled with debug information, includes the field types used in the program with their specifications, such as storage size. Therefore, it is possible to access run-time type information for a binary image without actually running the program. In other words, once a program is compiled and its debugging information is included in the object file, it can be accessed to determine the types of the defined fields in the program's data structures without actually executing the program. After the type information is obtained, other platform specification information, such as the type of compiler and processor, is determined. From the type information and platform specifications, field sizes can be ascertained and the corresponding offsets for data structure fields can be calculated to create the appropriate gopher program.
  • A “type library” is created including all the data types involved so that the necessary type information is available to calculate the correct offsets. For example, consider the following configuration, assuming that only two types, the integer and character primitive data types, will be used. In the Tornado® development environment with a target system running on a VxWorks® platform, an operating system distributed by Wind River Systems, Inc., the type library could be as simple as:
      • #include “vxworks.h”
      • #include “msgQLibP.h”
      • int main (int argc, char** argv) { }
        The above program has two variables, argc, an integer variable, and argv, a character variable. Compiling the above program with debug information produces a binary image with the integer and character type specifications (storage size) necessary for calculating the corresponding offsets (the type library binary image).
  • An exemplary embodiment of the present invention will be described with reference to the following configuration: the C programming language is used to code the type library; debugging is accomplished using a Gnu debugger; and a Perl script implements the gopher generator. With this configuration the gopher generator (Perl script) would invoke the Gnu debugger with the compiled, binary image of the type library. The generator sends function calls to the Gnu debugger to evaluate certain pre-defined instructions, or gopher generator commands, such as:
      • offset_of—returns the offset of a field within a structure
      • sizeof—return the size of a particular type
      • array_size—return the C arraysize of a variable
  • The debugger executes the functions, which examine the type library binary image to determine the size of a field and to determine a field position, and returns both to the generator script. These values are used to calculate the offset of a field within a structure (offset_of), the size of a particular type (sizeof), and the C array size of a global variable (array_size). Other gopher generator commands can also be implemented if desired.
  • The debug information may be included in the compiled image a number of ways, depending on the compiler used. For example, in the above configuration using the Gnu compiler, a “-g” switch is provided for such functionality.
  • The text file is read on a line by line basis and each line is scanned for the gopher generator commands: “offset_of”, “sizeof”, “array_size” outlined above. When a line contains one of these gopher generator commands, the gopher generator calls a corresponding function in the debugger. The debugger then executes the corresponding function and if successfully executed, the results are substituted in the input line. If the function fails, a fatal error is signaled in the input line and the gopher generator exits with an error.
  • Continuing with our example of extracting the maxmsgs value from the MSG_Q structure, to automatically create a gopher program for retrieving the value of maxMsgs, the following text line from an input command file is input to the gopher generator:
      • MSG_Qaddr<offset_of(MSG_Q.maxMsgs)@>
  • When the gopher generator parses the input line, it will see “offset_of,” and recognize it as a predefined gopher generator command, and call an offset_of function in the debugger with the argument “MSG_Q.maxMsgs,” which tells the function to return the offset of the variable maxMsgs in the data structure MSG_Q. By examining the binary image of the data structure in the type library binary image, the function ascertains that maxMsgs is an integer type, determines the configuration of the MSG_Q data structure, accesses the type information in the compiled binary image of the type library binary image to -determine the offsets of each variable in the MSQ_Q data structure, calculates the offset of maxMsgs, and returns the calculated offset value to the generator which then substitutes the offset value to yield the following line in the input command file:
      • MSG_Q_addr<+8@>
  • The gopher generator substitutes those gopher generator commands that it recognizes on a line by line basis. This allows the gopher generator to be extended to accommodate new gopher generator commands as and when they become necessary. For example, if an input line contained the following:
      • text-that-will-remain-before--+offset_of(MSG_Q.maxMsgs)@and-after Period;
        the result would be:
      • text-that-will-remain-before--+8@-and-after Period.
  • The generator replaces certain specified text, namely, the gopher generator commands, with the appropriate value (e.g., offset value, size value, array size value). This mechanism allows the arbitrary placement of text around the gopher generator command, and allows the use of any gopher program language elements since the gopher generator command elements are defined by the user.
  • To retrieve all values from the MSG_Q data, the following gopher program could be used:
      • MSG_Q_addr<+0@><+4@><+8@><+12@><+16@><+20@><+24@>
  • To automatically generate a gopher program with the correct offsets for retrieving all the data structure values, the following text is input to the gopher generator:
      • MSG_Q_addr <+offset_of(MSG_Q.next)$><+offset_of(MSG_Q.options)@>
      • <+offset_of(MSG_Q.maxmsgs)@><+offset_of(MSG_Q.maxMsgLength)@>
      • <+offset_of(MSG_Q.maxMsgsQueued)@><+offset_of(MSG_Q.sendTimeouts)@>
      • <+offset_of(MSG_Q.recvTimeouts)@>
  • If a gopher generator command included a member that did not exist, for example:
      • <+offset_of(MSG_Q.thisDoesNotExist)@>
        then it would produce a run-time error and no gopher program would be generated.
  • The input text file is preferably preprocessed by the pre-processor. This mechanism allows one file to include another. For example, the MSG_Q data type could be described in its own file. This could then be included by other files that would need access to MSG_Q members. This mechanism promotes the development of a type library. For example, the MSG_Q data structure could be stored in it's own file: “MSG_Q.gp”, and from another text file we could simply include it with “#include “MSG_Q.gp.”
  • FIG. 2 shows the interaction of the components of the system according to an embodiment of the present invention. The automatic gopher generator 20 accepts a command file 22 as input. The binary image of the type library 21 is fed to the debugger 24. The text file 22 is parsed for pre-defined gopher generator commands, and if found, the appropriate function call 27 is sent to the debugger 24 which, returns a value 25 that is substituted into the gopher generator command's corresponding position in the text file to produce a gopher program 26. The text file can then be saved under an appropriate file name or printed.
  • The process of the gopher program generator is shown in the flowchart of FIG. 3. The generator starts (step 30) by launching the debugging process (step 32) and feeding the type library binary image to the debugger (step 34). The generator then parses the command file line by line (step 36). After parsing a line of the input command file, the generator checks to see if it is at the end of the file (step 37). If so, then the generator returns the output (a gopher program) at step 38. Otherwise, if the generator is not at the end of the text file (step 37), the next step determines if one of the pre-defined gopher generator commands is present in the line (step 39). If there is not, the generator goes to the next line (step 46) and repeats parsing for the EOF (step 37) and pre-defined gopher generator commands (step 39) until either the EOF or a gopher generator command is found. Once a gopher generator command is found, its corresponding function is called (step 40). The function returns its result (step 42) and the generator determines if the returned result is an error (step 43). If an error is returned, the generator terminates (step 38). If there is a value returned (step 43), it is substituted in the place of the gopher generator command text (step 44). The generator then goes to the next line (step 46) and continues to parse the remainder of the input command file (step 36).
  • For a more detailed example, suppose that a type library is compiled with debug information, and that the type library binary image is in a file is called employee-type.o. Let us further suppose that the type library contains information regarding the data structure in Table 6.
    TABLE 6
    Data Structure
    struct employee_struct
      {
      int id;
      char* firstname;
      char* lastname;
      };
  • In addition, an employee.p command file contains the following:
    TABLE 7
    CommandFile
    !<+offsetOf(employee_struct.id)@>
    <+offsetOf(employee_struct.firstname)*$>
    <+offsetOf(employee_struct.lastname)*$>
  • The gopher program is invoked via the command line:
      • perl print-gp.pl employee-type.o employee.p.
        Breaking the command line down, “perl print-gp.pl” is the method of running the gopher generator Perl script (“print-gp.pl”). The two subsequent arguments are, respectively: the type library used by the debugger, and the command file that the gopher generator will use. If the type library (employee-type.o) is successfully loaded by the debugger, then the gopher generator program will first pre-process the command file (employee.p). The pre-processing stage will transform all lines that contain: #include <file-name> to the actual contents of the file whose name appears in <file-name>. In this case, for the sake of simplicity, there are no included files.
  • The gopher generator reads the contents of the now fully pre-processed command file line-by-line while looking for gopher generator commands. In this example, the only command used is “offsetOf”, which computes the offset of the given field.
  • According to the syntax of Perl, each command (in this case, gopher generator commands) in the input command file is followed by an open parentheses “(”, and the end of the command with a close parentheses “)”. The contents between the “(” and the “)” are the command's parameter. According to general computer programming principles, each command can take a variable number of parameters, including none.
  • If the input line contains a gopher generator command, then it is transformed according to that command. Taking the lines of “employee.p” one by one, the results are as follows. The first input line is:
      • !<+offsetOf(employee_struct.id)@>
        which matches the offsetOf command and gopher generator computes the offset of the id field within the ““employee_struct type”” via the debugger. If the employee_struct type has no id field, then a fatal error occurs and the command file (“employee.p) needs to be corrected. Since the id field does exist, and the rest of the line is copied verbatim, the full substitution for that line is:
      • !<+0@>
  • The next input line is:
      • <+offsetOf(employee_struct.firstname)*$>
        which also matches the “offsetOf” command and the gopher generator computes the offset of the “firstname” field within the “employee_struct” type via the debugger. In this example, it is clear that the “firstname” field is the second one in the data structure (See Table 6), following the “int id” field. The offset returned by the debugger is the distance from the start of the data structure to the start of the “firstname” field, which is consequently the size of an integer variable. The full substitution for this line is:
      • <+4*$>
        wherein “4” is the size of an integer value (in x86), and the “*$” command will later tell the gopher agent running on the target to de-reference the pointer at this offset's location and keep writing string data bytes to the tape until it encounters a terminating null.
  • The final output line is:
      • <+offsetOf(employee_struct.lastname)*$>
        which is the same as the previous command to get the first name, except that now it will use the computed offset of the lastname field. The substituted line is therefore:
      • <+8*$>
        as the debugger reports the offset of the struct field to be 8 now (the size of an int, plus the size of a pointer).
  • Since there are no more input lines from the command file, the gopher generator outputs (in this example, prints to a file or printer via the print-gp.pl command) a gopher program suitable for a gopherEval ( ) via WTX. The gopher program is the result of combining the input lines. For the “employee.p” command file, the generated gopher program is:
      • !<+0@><+4*$>+8 *$>
  • It should be noted that in most cases, a gopher program is used in conjunction with an initial pointer. In this case, assuming that the employee_struct data structure does not begin at memory location zero, a pointer to the beginning the employee_struct data structure on the target would be identified by the user (e.g., from a symbol table), and the pointer plus the above gopher program would be sent to the target via WTX.
  • In the preceding specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative manner rather than a restrictive sense.

Claims (22)

1. A method for creating a gopher program comprising the steps of:
accepting an input command file including literal text and a pre-defined instruction corresponding to a field of a compound data type;
parsing the input command file for the pre-defined instruction;
identifying the pre-defined instruction;
retrieving a field size and a field location from a type library binary image;
calculating a field value from the field location and the field size;
producing a gopher program including the literal text and the field value substituted in place of the pre-defined instruction.
2. The method of claim 1 wherein the field value is an offset value.
3. The method of claim 1 wherein the field value is the field size.
4. The method of claim 1 wherein the field value is an array size.
5. The method of claim 1 wherein the input command file further comprises a plurality of pre-defined instructions.
6. The method of claim 1 wherein the pre-defined instruction is a command.
7. The method of claim 1 wherein the pre-defined instruction is a macro.
8-42. (canceled)
42. A computer readable medium, having stored thereon, computer executable process steps operable to control a computer to generate a gopher program, said computer executable process steps comprising the steps of:
accepting an input command file including literal text and a pre-defined instruction corresponding to a field of a compound data type;
parsing the input command file for the pre-defined instruction;
identifying the pre-defined instruction;
retrieving a field size and a field location from a type library binary image;
calculating a field value from the field location and the field size;
producing a gopher program including the literal text and the field value substituted in place of the pre-defined instruction.
43. The computer readable medium of claim 42, wherein the field value is an offset value.
44. The computer readable medium of claim 42, wherein the field value is the field size.
45. The computer readable medium of claim 42, wherein the field value is an array size.
46. The computer readable medium of claim 42, wherein the input command file further comprises a plurality of pre-defined instructions.
47. The computer readable medium of claim 42, wherein the pre-defined instruction is a command.
48. The computer readable medium of claim 42, wherein the pre-defined instruction is a macro.
49. An automatic gopher program generating system, comprising:
a processor;
a data storage device operably connected to the processor, the data storage device incluing a program executable by the processor to perform steps including:
accepting an input command file including literal text and a pre-defined instruction corresponding to a field of a compound data type;
parsing the input command file for the pre-defined instruction;
identifying the pre-defined instruction;
retrieving a field size and a field location from a type library binary image;
calculating a field value from the field location and the field size;
producing a gopher program including the literal text and the field value substituted in place of the pre-defined instruction.
50. The system of claim 49, wherein the field value is an offset value.
51. The system of claim 49, wherein the field value is the field size.
52. The system of claim 49, wherein the field value is an array size.
53. The system of claim 49, wherein the input command file further comprises a plurality of pre-defined instructions.
54. The system of claim 49, wherein the pre-defined instruction is a command.
55. The system of claim 49, wherein the pre-defined instruction is a macro.
US11/158,250 2002-04-18 2005-06-21 Automatic gopher program generator Abandoned US20050235277A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/158,250 US20050235277A1 (en) 2002-04-18 2005-06-21 Automatic gopher program generator

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/124,843 US6938239B2 (en) 2002-04-18 2002-04-18 Automatic gopher program generator
US11/158,250 US20050235277A1 (en) 2002-04-18 2005-06-21 Automatic gopher program generator

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/124,843 Continuation US6938239B2 (en) 2002-04-18 2002-04-18 Automatic gopher program generator

Publications (1)

Publication Number Publication Date
US20050235277A1 true US20050235277A1 (en) 2005-10-20

Family

ID=29214660

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/124,843 Expired - Lifetime US6938239B2 (en) 2002-04-18 2002-04-18 Automatic gopher program generator
US11/158,250 Abandoned US20050235277A1 (en) 2002-04-18 2005-06-21 Automatic gopher program generator

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/124,843 Expired - Lifetime US6938239B2 (en) 2002-04-18 2002-04-18 Automatic gopher program generator

Country Status (1)

Country Link
US (2) US6938239B2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080301644A1 (en) * 2007-05-30 2008-12-04 Ulrich Drepper Facilitating availability of object data types at runtime
US20120246653A1 (en) * 2011-03-23 2012-09-27 Infinidat Ltd. Generic command parser
CN108628603A (en) * 2017-03-16 2018-10-09 北京京东尚科信息技术有限公司 A kind of method, apparatus, equipment and storage medium that time setting value is provided

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7073168B2 (en) * 2001-12-06 2006-07-04 Microsoft Corporation Customizing binary content files
US7506048B1 (en) * 2002-06-05 2009-03-17 Ricoh Co. Ltd. Method and system for monitoring network connected devices and displaying device status
US7908580B2 (en) * 2006-09-07 2011-03-15 Microsoft Corporation Connecting an integrated development environment with an application instance
US8850388B2 (en) * 2006-09-07 2014-09-30 Microsoft Corporation Controlling application features
US9152536B1 (en) * 2014-05-19 2015-10-06 International Business Machines Corporation Validating correctness of expression evaluation within a debugger
CN108614680A (en) * 2016-12-14 2018-10-02 中国航空工业集团公司西安航空计算技术研究所 A kind of automatic generation method and system of information inquiring command program
CN112463818B (en) * 2020-11-24 2022-07-12 苏州浪潮智能科技有限公司 Method, medium, equipment and system for inquiring information of storage bottom layer

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5412808A (en) * 1991-07-24 1995-05-02 At&T Corp. System for parsing extended file names in an operating system
US5754844A (en) * 1995-12-14 1998-05-19 Sun Microsystems, Inc. Method and system for accessing chunks of data using matching of an access tab and hashing code to generate a suggested storage location
US5905649A (en) * 1996-09-23 1999-05-18 National Instruments Corporation System and method for performing type checking and class propagation of attributes in a graphical data flow program
US5909580A (en) * 1996-02-08 1999-06-01 Inprise Corporation Development system and methods with direct compiler support for detecting invalid use and management of resources and memory at runtime
US6343328B1 (en) * 1997-02-10 2002-01-29 International Business Machines Corporation Digital computer system using embedded comments to manipulate virtual controller functions
US6442663B1 (en) * 1998-06-19 2002-08-27 Board Of Supervisors Of Louisiana University And Agricultural And Mechanical College Data collection and restoration for homogeneous or heterogeneous process migration
US20030056197A1 (en) * 2001-08-30 2003-03-20 Dennis Peter D. J. Method and apparatus to facilitate debugging computer code within an operating system kernel
US6694510B1 (en) * 2000-11-03 2004-02-17 Hewlett-Packard Development Company, L.P. Collection driver for collecting system data using record based requests with tag lists and pausing all but one thread of a computer system
US6801911B1 (en) * 1997-11-21 2004-10-05 International Business Machines Corporation Data processing system and method for accessing files
US6983452B1 (en) * 2000-11-03 2006-01-03 Hewlett-Packard Development Company, L.P. System and method for collecting system data using record based requests with tag lists and pausing all but one thread of a computer system
US7099866B1 (en) * 2001-11-16 2006-08-29 Hewlett-Packard Development Company, L.P. Method of generating and presenting kernel data
US20060235811A1 (en) * 2002-02-01 2006-10-19 John Fairweather System and method for mining data

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5267175A (en) * 1986-09-12 1993-11-30 Digital Equipment Corporation Data base access mechanism for rules utilized by a synthesis procedure for logic circuit design
US6212575B1 (en) * 1995-05-05 2001-04-03 Apple Computer, Inc. Extensible, replaceable network component system
US6029002A (en) * 1995-10-31 2000-02-22 Peritus Software Services, Inc. Method and apparatus for analyzing computer code using weakest precondition
US5987517A (en) * 1996-03-27 1999-11-16 Microsoft Corporation System having a library of protocol independent reentrant network interface functions for providing common calling interface for communication and application protocols
US6085186A (en) * 1996-09-20 2000-07-04 Netbot, Inc. Method and system using information written in a wrapper description language to execute query on a network
US6460058B2 (en) * 1996-12-06 2002-10-01 Microsoft Corporation Object-oriented framework for hyperlink navigation

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5412808A (en) * 1991-07-24 1995-05-02 At&T Corp. System for parsing extended file names in an operating system
US5754844A (en) * 1995-12-14 1998-05-19 Sun Microsystems, Inc. Method and system for accessing chunks of data using matching of an access tab and hashing code to generate a suggested storage location
US5909580A (en) * 1996-02-08 1999-06-01 Inprise Corporation Development system and methods with direct compiler support for detecting invalid use and management of resources and memory at runtime
US5905649A (en) * 1996-09-23 1999-05-18 National Instruments Corporation System and method for performing type checking and class propagation of attributes in a graphical data flow program
US6343328B1 (en) * 1997-02-10 2002-01-29 International Business Machines Corporation Digital computer system using embedded comments to manipulate virtual controller functions
US6801911B1 (en) * 1997-11-21 2004-10-05 International Business Machines Corporation Data processing system and method for accessing files
US6442663B1 (en) * 1998-06-19 2002-08-27 Board Of Supervisors Of Louisiana University And Agricultural And Mechanical College Data collection and restoration for homogeneous or heterogeneous process migration
US6694510B1 (en) * 2000-11-03 2004-02-17 Hewlett-Packard Development Company, L.P. Collection driver for collecting system data using record based requests with tag lists and pausing all but one thread of a computer system
US6983452B1 (en) * 2000-11-03 2006-01-03 Hewlett-Packard Development Company, L.P. System and method for collecting system data using record based requests with tag lists and pausing all but one thread of a computer system
US20030056197A1 (en) * 2001-08-30 2003-03-20 Dennis Peter D. J. Method and apparatus to facilitate debugging computer code within an operating system kernel
US7099866B1 (en) * 2001-11-16 2006-08-29 Hewlett-Packard Development Company, L.P. Method of generating and presenting kernel data
US20060235811A1 (en) * 2002-02-01 2006-10-19 John Fairweather System and method for mining data

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080301644A1 (en) * 2007-05-30 2008-12-04 Ulrich Drepper Facilitating availability of object data types at runtime
US8042099B2 (en) * 2007-05-30 2011-10-18 Red Hat, Inc. Facilitating availability of object data types at runtime
US20120246653A1 (en) * 2011-03-23 2012-09-27 Infinidat Ltd. Generic command parser
CN108628603A (en) * 2017-03-16 2018-10-09 北京京东尚科信息技术有限公司 A kind of method, apparatus, equipment and storage medium that time setting value is provided

Also Published As

Publication number Publication date
US6938239B2 (en) 2005-08-30
US20030200525A1 (en) 2003-10-23

Similar Documents

Publication Publication Date Title
US20050235277A1 (en) Automatic gopher program generator
US5680622A (en) System and methods for quickly detecting shareability of symbol and type information in header files
Holub Compiler design in C
US7237231B2 (en) Automatic identification of input values that expose output failures in a software object
US5761510A (en) Method for error identification in a program interface
US6317871B1 (en) System for ensuring the accuracy of file structures in a source-to-source computer program translator
US5758061A (en) Computer software testing method and apparatus
US7484205B2 (en) Preprocessor-based source code instrumentation
US7962905B2 (en) Flexible and extensible java bytecode instrumentation system
US8458681B1 (en) Method and system for optimizing the object code of a program
US6931627B2 (en) System and method for combinatorial test generation in a compatibility testing environment
JP5415557B2 (en) User script code conversion for debugging
US8645938B2 (en) System and method for replacing code
US20060212847A1 (en) Type checker for a typed intermediate representation of object-oriented languages
US20120096446A1 (en) Parsing of declarations in all branches of preprocessor conditionals
US7240340B2 (en) System and method for browse information parsing without compilation
US6986124B1 (en) Debugger protocol generator
US7032213B1 (en) Fixing incompatible applications using a light debugger
KR20040097909A (en) Reflection-based processing of input parameters for commands
Poll et al. Specification of the Javacard API in JML: Towards formal specification and verification of applets and API implementations
JPH1040114A (en) Compile method for c++ program and compiler
US20080313208A1 (en) Apparatus, system, and method for automated context-sensitive message organization
US7703077B2 (en) Programming model to detect deadlocks in concurrent programs
US20060161896A1 (en) Performing debug requests that are within the debug domain of a class loader
Parr et al. Pccts reference manual: version 1.00

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION