Abstract:
The present symbol renaming process allows a symbol in a first source code file to be renamed by the linker. This allows new layers of software to be added under an existing interface without recompiling existing code. Symbol renaming in the linker also allows a programmer to easily fix mismatched symbols in linked files without recompiling the source code in all of the linked files. The linker scans a first intermediate object code file to detect a substitution indicator indicating a variable or function in a second file is to be renamed. The symbol to be replaced is read and then the substitution symbol is read. The linker then replaces every occurrence of the symbol as the symbol is read from a second file with the substitution symbol in the intermediate code file generated by the linker.

Description:
FIELD OF THE INVENTION 
     This invention relates to a compiler that generates executable software applications from source code written in a programming language. More particularly, this invention relates to a linker in a compiler that allows symbols in an intermediate object code file and/or library to be renamed without recompiling the source code for the intermediate object code file and/or library. 
     PROBLEM 
     In order to produce executable programs for computer systems, computer programmers write source code in a programming language. Some examples of programming languages are C, C++, Fortran, Pascal, and Visual Basic. In order to convert the source code into code that can be read by a processor, the source code is input into a compiler that converts the source code into machine readable code. 
     It is common for the source code of a software application to be written in many different phases or in many different components. For example, several programmers may each be working on a different aspect of an application or a new feature may be added to an existing application to improve performance of the application. Different flies containing the different components of an application are joined together by a linker in a compiler while the executable code is being generated. 
     The linker is an editor that checks each file to make sure that the terms or symbols from the different flies agree. For purposes of the present discussion, a symbol is a name identifying any variable or function in the source code. If the symbols for a particular variable or function do not agree in multiple files of an application, the linker detects an error. When an error is detected by the linker, the linker either raises flags indicating possible mismatches or does not allow the files to be compiled into executable code. When a symbol mismatch occurs, the programmer or programmers must go back into each file of source code for the application and find the mismatched symbol. The mismatch must then be corrected and the files must each be recompiled and applied to a link editor. This is a problem because every file containing source code must be corrected and then re-compiled in order to make executable code. 
     Furthermore, when a file containing a new layer of is added to an application, each source file must be recompiled to assure matching symbols for each object. This is a waste of processing time to recompile unchanged code. It would instead be desirable to allow new layers of software to be added and call an existing defination without recompiling the existing code. There is a need in the art for a process performed by a linder in a compiler that reduces the acount of files that must be recompiled when a new layer of software is added to an application. 
     SOLUTION 
     The above and other problems are solved and an advance in the art is made by the system for automatically remaning symbols in files during the compiling of the files, termed “symbol remaning process” herein. Symbol remaning allows a symbol in a first file or library to be remaned by the linker. This allows new layers of software to be added under an existing interface without recompiling existing code. Symbol renaming in the linker also allows a programmer to easily fix mismatched symbols in linked files without recompiling the source code in all of the linked files. 
     In order to convert source code into executable code, the source files containing the source code must be processed by a compiler, linker, and a constructor. Each source file is first processed by a compiler. The compiler is comprised of a scanner, a parser and a semantic checker. The scanner scans each file to detect each symbol or token in the file. The parser detects the structure of expressions in the language to detect each expression. The semantic checker determines the meaning of each symbol in an expression. The intermediate code generator than generates a file of intermediate object code for each file of source code. The intermediate object code file represents the data structures and functions defined in the source code file as determined by the semantic checker. 
     After all of the files of source code have been compiled into intermediate object code files, the intermediate object code files are applied to a linker which joins the files of intermediate object code into one file. The linker checks for agreements between symbols declared in each source code file. If there is an error in agreement in symbol types, the linker either flags the error and indicates the error to the programmer(s) or does not allow the files to be linked. After the files have been linked, the resulting file is applied to a constructor which generates an executable file. 
     The present symbol renaming process performs the symbol renaming in the linker in the following manner. The linker scans a first intermediate object code file to detect a substitution indicator indicating a variable or function in a second file is to be renamed. The symbol to be replaced is read and then the substitution symbol is read. The linker then replaces every occurrence of the symbol as the symbol is read from a second file or library with the substitution symbol in the intermediate code file generated by the linker. 
    
    
     DESCRIPTION OF THE DRAWINGS 
     This invention can be understood by reading the below detailed description and studying the following drawings: 
     FIG. 1 illustrating a block diagram of a computer processing system; 
     FIG. 2 illustrating a flow diagram of a compiler for an object oriented language; 
     FIG. 3 illustrating a flow diagram of an overview of this invention; 
     FIG. 4 illustrating a flow diagram for detecting a substitution indicator in a first file; 
     FIG. 5 illustrating a flow diagram for generating a replacement queue; 
     FIG. 6 illustrating a flow diagram for symbol substitution performed in a linker; and 
     FIG. 7 illustrating a C++ language compiler that performs symbol renaming. 
    
    
     DETAILED DESCRIPTION 
     Exemplary Computer Processing System—FIG. 1 
     FIG. 1 illustrates a block diagram of an exemplary computer processing system  100  that may execute the software applications that provide symbol renaming in a linker for files and libraries generated in a compiler. Computer processing system  100  has a Central Processing Unit (CPU)  101 . CPU  101  is a processor which executes instructions read from memory to run software applications. Memory bus  102  connects CPU  101  with memory units to allow CPU  101  to read and write data to memory. Read Only Memory (ROM)  105  connects to memory bus  102  via path  103 . ROM  105  contains instructions that are required to operate computer processing system  100 . Random Access Memory (RAM)  106  is connected to memory bus  102  via path  104 . RAM  106  stores data and instructions needed to execute software applications. 
     I/O bus  110  is used by CPU  101  to receive data from and transmit data to I/O devices. I/O devices connected to CPU  101  may include but are not limited to input device  116 , display  117 , network interface  118 , and memory  119 . Input device is connected to I/O bus  110  via path  111  and allows a user to input data. Examples of an input device  116  include but are not limited to a keyboard, a mouse, and a microphone. Display  117  is connected to I/O bus  110  via path  112 . Display  117  is a video driver and connected display which allows computer system  110  to display data to a user. Network interface  118  is connected to I/O bus  110  via path  113  and connects to a network (not shown) via path  120  to allow communication between computer processing system  100  and other computer processing systems. Some examples of network interface  118  include but are not limited to Ethernet drivers and modems. Memory  119  is a device that stores can store data such a disk drive which can read and write data to a storage media. Media  119  is connected to I/O bus  110  via path  114 . 
     Overview of the Present Invention. 
     The present symbol renaming process operates by compiling files of source code written in a programming language into executable code. In order to provide symbol renaming in a linker, the processes for the linker and the compiler must be modified. The compiler must be modified to allow a detection of a command to replace a symbol in an object file or library and the linker must be modified to perform the substitution. In the following discussion, an exemplary compiler that could be used to convert a file written in a programming language to an executable file is provided. An overview of the present symbol renaming process is then provided along with the processes for modifying the components of a compiler to provide symbol renaming in a linker. Finally, an exemplary C++ compiler is provided and the modifications to the C++ compiler to provide symbol renaming in a linker are explained. 
     A Compiler for An Object Oriented Language—FIG. 2 
     FIG. 2 illustrates an object oriented language compiler that provides symbol renaming in a linker. A specific example of a compiler  200  that provides symbol renaming in a linker is provided in FIG. 7 which illustrates a C++ compiler. In FIG. 2, compiler  200  includes scanner  201 , parser  202 , semantic checker  203 , intermediate code generator  204 , linker  205 , and constructor  206 . Each of the components of compiler  200  is a software application that is executed by computer system  100  to complete the conversion of a source file or multiple source files from a file containing source code written in a programming language into a file containing machine readable code. Those skilled in the art will recognize that any and/or all of the various components may be combined to perform the essential functions of compiler  200 . 
     Compiler  200  receives source code file  250 . First, scanner  201  divides source file  250  into individual tokens. Tokens are words and letters. Parser  202  then divides the token into statements in the syntax and grammar of the programming language supported by compiler  200 . While the tokens are being divided into statements, parser  202  also detects errors in the syntax of the code in source file  250 . Semantic checker  303  then extracts the context independent meaning of tokens or symbols from the parsed source code and determines the meanings of the parsed statements from file  250  in the supported language. Intermediate code generator  204  then generates an intermediate object code file  220  of source file  250 . The intermediate object code file  220  may contain a parse tree for the functions and data structures that defines the tokens and statements in source file  250 . The intermediate object file  220  for source file  250  also contains a symbol table  221  and virtual function table  222  for each object in source file  250 . 
     Scanner  201 , parser  202 , semantic checker  203 , and intermediate code generator  204  create a symbol table  221  and virtual function table  222  in intermediate object code file  220  as source file  250  is being checked. Symbol table  221  is an array of individual symbol tables for each object in the source file  250 . The individual symbol tables include each variable, dynamic and static, declared in an object and are used to determine scope of a variable in an object. The individual symbol tables are then used during creation of the executable code to allocate memory to hold the variables. 
     Virtual function table  222  is an array of individual functions tables that store the functions that can be performed in each object. There is an individual function table for each object. The virtual function table  222  is used during the creation of executable code to determine that a particular function can be performed on or by an object. If compiler  200  is compiling an object oriented language, the virtual function table is created by storing all of the functions inherited from a super class object into the individual function table for a subclass as well as functions created to specifically manipulate members of the subclass object. for a single application and generates one intermediate object file. As the linker is combining the intermediate object files, linker  205  checks to determine that all functions and classes declared in the files are defined in the resulting intermediate object file. If all of the functions and classes are defined in the resulting file, constructor  206  generates executable code in an executable file from the intermediate object code in the resulting file which includes symbol table  221  and virtual function table  222 . 
     A Process For Renaming Variables in a Linker—FIG. 3 
     Process  300  illustrated in FIG. 3 is an overview of the present symbol renaming process. Process  300  begins with a first source file being scanned in step  301 . In step  302 , a second file substitution indicator is detected. The second file substitution indicator is a token that in indicates a substitution for a symbol in a second file is to be made. An example of a commonly known symbol is a #typedefine symbol in C++ which indicates substitution in a file. In response to detecting a second file substitution indicator, the symbol to be replaced is read in step  303 . In step  304 , the substitute symbol is read from the first file. Process  300  ends after step  305  in which the linker substitutes the substitute symbol for the symbol every time the symbol occurs in the intermediate object code file generated by the linker. 
     Process for Detecting a Substitution Indicator in a First File—FIG. 4 
     Process  400  illustrated by FIG. 4 is a process for detecting a linker substitution indicator. Process  400  is a process executed by semantic checker  203  when an indicator in detected in a file. Process  400  represents a change the lexicography rules in the compiler. One skilled in the art will be able to change the lexicography rules in compiler  200  to perform process  400 . Process  400  begins in step  401  with a substitution indicator being detected in first file containing source code. In step  402 , the symbol to be replaced is read from the expression containing the indicator and in step  403 , the substitute symbol is read from the expression. In step  404 , intermediate object code is generated and a linker substitution indicator is written to the intermediate object file for the first file. 
     Process for Detecting Substitution Indicator in Linker  205 —FIG. 5 
     Process  500  illustrated in FIG. 5 is the process in linker  205  for detecting a substitution is required in an intermediate object file. Process  500  is the process by which linker  205  detects that substitutions are required and generates a substitution queue to perform the substitutions. Process  500  executed every time a linker substitution indicator is read from an intermediate object code file that has been generated using process  400 . A second process described below then performs the substitution. 
     Process  500  begins in step  501  with a linker substitution indicator being read from the intermediate object code of the first file. In step  502 , the symbol to be replaced is read. The substitute symbol is then read in step  503 . Process  500  ends in step  504  storing the symbol and substitute symbol in an entry in a substitution queue. Process  500  then returns to the main routine of linker  205  to complete the generation of the linked intermediate object file. 
     Process for Substituting a Substitute Symbol for a Symbol in the Linked Intermediate Object File—FIG. 6 
     Process  600  is an embodiment of a process that can be used to complete the substitution of symbols by linker  205 . Process  600  is completed after all of the source intermediate object files and libraries have been added to the linked intermediate object file. It should be understood that one skilled in the art could design any number of processes for completing the substitutions. 
     Process  600  begins in step  601  by reading a symbol to be replaced from the substitution queue generated by process  500 . In step  602 , the corresponding substitute symbol is read. The linked object file is then read in step  603 . When the symbol read in step  601  is detected in step  604 , the symbol is replaced by the substitute symbol read in step  605 . Linker  205  then determines whether the linker is at the end of the file in step  606 . If linker  205  is not at the end of the file, steps  603 - 606  are repeated. Otherwise, linker  205  determines whether the substitution queue contains a next symbol. If the substitution queue does contain another symbol, process  600  is repeated from step  601 . If the substitution does not contain another symbol, process  600  ends. 
     An Exemplary Embodiment of C++ Compiler That Provides Flat References in Accordance With the Present Symbol Renaming Process—FIG. 7 
     C++ Compiler  700  is illustrated in FIG.  7 . C++ compiler  700  is a preferred exemplary embodiment of a compiler that can provide the symbol renaming of the linker in accordance to this invention. Files containing C++ code are converted into an executable file by C++ compiler  700 . Source file  701  is received by preprocessor  702 . Preprocessor  702  is a common C++ compiler software component that adds all of the included files and libraries into source file  701  to form intermediate C file  703 . Compiler  704  receives the intermediate C file  703  and performs scanning, parsing, semantic checking, and intermediate code generating to produce symbol table  321 , virtual function table  322  and an intermediate code file  350  for source file  701 . Process  400  described above is performed by compiler is a routine added to the semantic checking in compiler  700  to detect a substitution indicator for substitution by the linker. The results of the compiler  704  are stored in an intermediate object file (.o file)  750 . Linker  705  receives all of the intermediate object files  750  that are needed to produce an application and links the files into one linked file  751 . It should be understood by those skilled in that translation, C compiling, and debugging software can be performed upon the intermediate object code generated by compiler  704 . Linker  705  ensures that all imported and exported objects are declared, defined and in agreement. Linker  705  performs process  500  as linker substitution indicators are encountered and creates a linked intermediate object file and performs process  600  on linked intermediate object file. Linker  705  then generates the executable code in executable file  707  from the linked intermediate object files. Executable file  707  can be executed by computer system  100  to run the software application.