Abstract:
An object file server provides when used with a debugger, for example, a universal debugger capable of debugging files ( 103 ) with different file formats. The object file server includes a core ( 107 ) and multiple target specific readers ( 109   1 - 109   n ) which are sequentially coupled to the files and a target specific readers read the files and the information from the files is stored in the core ( 107 ). The object file server includes a client debugger interface ( 107   b ) for reading the information from the core ( 107 ) to the debugger ( 105   a ) in a single format.

Description:
COPYRIGHT NOTICE  
         [0001]    Portions of this patent document contain material which is subject to copyright protection. The copyright owner, Texas Instruments Inc., has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the U.S. Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever.  
           [0002]    1. Field of the Invention  
           [0003]    This invention relates to an object file server and more particularly to an object file server that can read from, or write to, multiple formats.  
           [0004]    2. Background of the Invention  
           [0005]    Software development for applications on microcontrollers, microprocessors and/or digital signal processors may involve a host debugger and/or linker. A compiler translates a source code into an assembly language code. An assembler translates the assembly language source code files into machine language object files. A linker combines the object files into a single executable program. The linker accepts object files created by the assembler as input. The linker also accepts active or library member and output modules or programs created previously. The objective of the process is to produce an executable program or module that may be stored and executed on the microcontroller or microprocessor. The microcontroller and/or digital signal processor may be in a device such as a cellular telephone.  
           [0006]    Debugging tools are available to test the processors and executable code. Application software development requires a level of simulation, observability and controllability of the software within the hardware system being developed. Tools for debugging software in a system context includes simulators and emulators. An emulator is a software development tool that allows software under development to be executed, controlled and viewed in a real hardware environment.  
           [0007]    Debugging tools or linkers are configured to accept a given single computer format such as GNU or Microsoft format. It is highly desirable to provide a debugger or a linker that will accept object files of computer formats from different computer vendors.  
         SUMMARY OF THE INVENTION  
         [0008]    In accordance with one embodiment of the present invention, an object file server is provided that can read object codes in multiple computer formats and present a single unified format.  
           [0009]    In accordance with another embodiment of the present invention, a debugger is provided that can read multiple object file formats.  
           [0010]    In accordance with another embodiment of the present invention, an object file server is provided that writes object code to multiple computer formats. 
       
    
    
     DESCRIPTION OF THE DRAWINGS  
       [0011]    [0011]FIG. 1 is a block diagram of an object file server in a system according to one embodiment of the present invention.  
         [0012]    [0012]FIG. 2 is a flow chart of the operation of the file server according to one embodiment of the present invention.  
         [0013]    [0013]FIG. 3 is a visual linker system block diagram with an object file server.  
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0014]    Referring to FIG. 1, the object file server  101  is coupled between files  103  and a client  105 , such as a host debugger target  105   a  or visual linker target  105   b.  The object file server  101  includes a Dynamic Link Library (DLL) core object file server  107  and target specific DLL readers  109   1 - 109   n . The files may be, for example, GNU/ARM format files, Microsoft ARM format files or Texas Instruments TI COFF object files and ARM object format files  103 . For each file format, the object file server  101  provides a target specific DLL reader  109   1 - 109   n . The operation of the object file server  101  is illustrated in FIG. 2. In the first step  201 , the client  105  (host target debugger or visual linker for example) requests file be loaded and gives a file name. The object file server  101  locates the target specific reader  109   1 - 109   n  in step  202 . One by one each reader  109   1 - 109   n  looks at the file in step  203  and determines if it can read the object file format the client requests. When each reader  109   1 - 109   n  reads the raw data in the object file, it examines the first few bytes in the file to determine which format the data is in. The file ends up getting read into the core server  107  to look at it. An interface  107   a  in the core  107  is exposed so the reader  109   1 - 109   n  calls back to the core  107  and starts sending information and the core  107  builds its own representation of what is in the file. The object file contains a number of sections associated with the sections is a name, starting address, local address, length, kind, relocation information and data. The object file also contains global variables and local variables. If the file can be read (step  204 ) the OFS (step  205 ) core server  107  tells the reader  109   1 - 109   n  to read the file, figure it out (decode information program and debug information) and pass it into the core  107  to amass (store) all information. If no, the OFS goes to the next reader and repeats till a reader is found. Once OFS core  107  receives the information, the client  105  is told it is ready to read and the client reads the file.  
         [0015]    You may access all information from the object file:  
         [0016]    a. section information  
         [0017]    b. global variables  
         [0018]    c. local variables  
         [0019]    d. call stack information  
         [0020]    e. actual data in each section  
         [0021]    f. relocation information, for each relocatable object file  
         [0022]    g. user defined types. These include the C++ “struct”,“union”,“class”, and “enum” types declared in the user&#39;s code.  
         [0023]    The following is a list of OFS interfaces  107   b  for the client. Not all interfaces are listed, just the major ones:  
         [0024]    1. Cobject_file_server. This C++ class is used only once, to read in one object file. You create an object of this type, and then ask it to read in an object file.  
         [0025]    a. Some object files do not specify “Big endian” or “little endian”, so the OFS user must specify:  
         [0026]    void set_target_endian (bool is_big_endian);  
         [0027]    b. Read in an object file, given the name:  
         [0028]    Cofs_file_info_* read_object_file (char* file_name);  
         [0029]    c. Read in an object file from an archive. This interface does not specifically know what kind of archive you have, just that you have opened a C “FILE”, have put the current file pointer to the correct spot in the file, and can specify how many bytes are in this object:  
         [0030]    Cofs_file_info*read_object_file_from_archive (FILE*file_ptr, int size/*bytes*/);  
         [0031]    d. Get an error description:  
         [0032]    enum ofs_error_codes get_error (Strings &amp; error_string);  
         [0033]    e. C++ programs will produce “mangled names” for procedure names. This procedure will help to produce a demangled, or “normal” looking name for the procedure name or variable name:  
         [0034]    static char*demangle_name (char* mangled_name, bool full_name, bool &amp; success);  
         [0035]    f. the product versdion string may be helpful:  
         [0036]    const char*get_product_version ( ) const;  
         [0037]    2. Cofs_file_info. Once you have read in an object file (by asking the Cofs_object_server to do so), this class will offer access to all the data in the object file.  
         [0038]    a. All object files will have an endian-ness associated with them:  
         [0039]    bool is_big_endian ( ) const;  
         [0040]    b. The object files read in may currently be compiled for the following architectures:  
         [0041]    ARM, TI C 60 , TI C 54 x, TI C 55 x, TI C 27 x, TI  2 xx, TI  50 , TI C 3 x/C 4 x  
         [0042]    To find out which architecture applies to this object file:  
         [0043]    int get_processor_type ( ) const;  
         [0044]    c. All object files have a starting address:  
         [0045]    ofs_target_address get_starting_address ( )const;  
         [0046]    d. All object files will have a number of sections:  
         [0047]    int get_num_sections ( ) const;  
         [0048]    Cofs_section_info*get_section (int index) const;  
         [0049]    e. All object files have a number of global symbols. These will include global variables, C/C++ functions, assembly functions, and some absolute values given by the linker:  
         [0050]    int get_num_global_symbols ( ) const;  
         [0051]    Cofs_symbol_info*get_global_symbol (int index) const;  
         [0052]    f. To look up global symbols:  
         [0053]    int find_global_symbol (ofs_target_address addr) const:  
         [0054]    int find_global_symbol (const char*name) const;  
         [0055]    g. For C/C++, the user&#39;s struct/union/class/enum&#39;s, otherwise known as User Defined Types (UDT), may be accessed:  
         [0056]    int get_num_udt ( );  
         [0057]    TYPE*get_udt (int index);  
         [0058]    TYPE*add_a_udt (TYPE*the_type);  
         [0059]    TYPE*find udt (const char*name) const;  
         [0060]    h. C/C++ line number information is also generalized:  
         [0061]    Cofs_line_num_entry*lookup_line_num_from_address (ofs_target_address  
         [0062]    address, Cofs_function_info*&amp; function);  
         [0063]    3. Cofs_section info. There will be one of these objects for each section in the object file.  
         [0064]    The following information may be accessed for each section:  
         [0065]    name  
         [0066]    size in bytes  
         [0067]    a pointer to the raw section data  
         [0068]    the “run location” and the “load location” 
         [0069]    memory page number  
         [0070]    relocation entries for this section  
         [0071]    flags, including “is_writeable”, “is_allocated”, and “is_exec_instructions”.  
         [0072]    4. Cofs_location.  
         [0073]    Many items in an object file have associated locations:  
         [0074]    global variables  
         [0075]    global procedures  
         [0076]    local variables  
         [0077]    The Cofs_location object is generalized, and may be made up of various types of information:  
         [0078]    a. register numbers  
         [0079]    b. offsets from a register  
         [0080]    c. absolute addresses  
         [0081]    d. an indication of “indirect”, meaning that the debugger/user would read the value at the currently indicated address/register, and then use that value as the address indicated.  
         [0082]    e. a “number of bits” used in the address. This concept occurs when you have different sized memory models. For example, in the TI C 54 x product, an address is normally 16 bits long, but in “large memory model” an address is 22 bits long.  
         [0083]    5. Cofs_lexical scope.  
         [0084]    A lexical scope consists of a low address and a high address.  
         [0085]    a. functions. The lexical scope indicates the valid PC values of the function.  
         [0086]    b. local variables. Variables in a procedure may have the entire lexical scope of the procedure, but if a sub-scope is introduced, then the lexical scope will be smaller than the entire procedure.  
         [0087]    6. Cofs_line_num_entry.  
         [0088]    line number entries consist of:  
         [0089]    a. a file name  
         [0090]    b. a line number  
         [0091]    c. an address  
         [0092]    Each line of C/C++ code will produce a line number entry.  
         [0093]    7. Cofs_symbol_info.  
         [0094]    Each symbol in the object file will have an associated Cofs_symbol_info object. Information included in the symbol includes:  
         [0095]    a. name  
         [0096]    b. type (A generalized type model is used to encompass the entire C++ type model).  
         [0097]    c. section number that this symbol is in.  
         [0098]    d. symbol type (variable, function parameter, function, absolute symbol).  
         [0099]    e. symbol scope (global, static, local).  
         [0100]    f. a list of location/ranges. This info only applies to local variables. we may indicate this information thru the location/ranges.  
         [0101]    g. lexical scope.  
         [0102]    h. if this is a function, it will have a Cofs_function_info, described next.  
         [0103]    8. Cofs_function_info.  
         [0104]    Each function with an object file will be represented by one of these objects. Note that there will already be a Cofs_symbol_info object objects. Note that there will already be a Cofs_symbol_info object (described above), and this object contains extra info, that only applies to functions.  
         [0105]    Information for each function includes:  
         [0106]    a. local variables  
         [0107]    b. line number entries  
         [0108]    c. call stack information. At any point during the execution of a procedure, a debugger may want to construct a “call stack”, to indicate the procedures that called other procedures, leading onto the currently executing procedure. The data necessary to construct a call stack is the “return address”, and the “previous stack pointer”. This information has been generalized such that the user may request this information, giving the current PC value, and 2 Cofs_location objects will be returned, to indicate the previous frame pointer, and the return address.  
         [0109]    The core presents a unified format to the client which may be a debugger. Therefore, with the OFS the debugger can debug various formatted files. The client may also be a visual linker that can link various formatted files.  
         [0110]    In accordance with another embodiment of the present invention the separate code can understand how to write the information to a different format. For example a switch on a visual linker selects TI format or Microsoft format for example with a target specific writer. For example the files being loaded may be in TI format and linked in Microsoft format so a Microsoft debugger could understand it.  
         [0111]    Referring to FIG. 3 there is illustrated object files  31 - 33  to be applied to visual linker  35 . There may be hundreds of such files. For each file there is an object file reader server  31   a,    32   a,    33   a,  etc. with DLL target specific readers  131   a - 131   n,    132   a - 133   n,    133   a - 133   n,  etc.and OFS cores  31   b,    32   b,    33   b,  etc. to store and provide interfaces (like  107   a  and  107   b  in FIG. 1) to the readers and visual linker  35  to provide to the visual linker the information in a single format as disclosed above in connection with FIG. 1. The output would include a similar arrangement for writer servers. There is an object file server writer server  41  with DLL target specific writers  141   a - 141   n  and corresponding OFS core  41   b  to store and write to a specific targets  50   a - 50   n  in their specific formats with a target specific writers  141   a - 141   n  to write out the new executable file. The unified format from the linker  35  would be applied to the writer/core  41   b,  which then looks for the target specific writers  141   a - 141   n  to write to the specific target in the appropriate format.  
         [0112]    Copyright (c) 1998-2000 Texas Instruments Incorporated  
         [0113]    The OFS is intended to be a DLL, to be used as a generic reader of object files.  
         [0114]    Input files may be:  
         [0115]    a. TI COFF/stabs or TI COFF/DWARF for the following targets:  
         [0116]    ARM, C 60 , Ankoor, Lead, Lead 3 , C 3 x, C 24 x  
         [0117]    b. ARM ELF/DWARF. The old AIF/AOF formats are not supported.  
         [0118]    c. GNU/ARM/PE/stabs  
         [0119]    d. Microsoft WinCE ARM. For this to work, the .pdb file must not be used. Instead, use the pdb:none switch, and delete the /debugtype switch.  
         [0120]    HOW TO USE the OFS, to read an object file:  
         [0121]    1. Create an object file server:  
         [0122]    ofs::Cobject_file_server*an_ofs=new ofs::Cobject_file_server( );  
         [0123]    2. Call an_ofs→act_as_a_dumper( ) if your program is a dumper.  
         [0124]    (This functionality is mainly to automate testing).  
         [0125]    3. If you are using the GNU/arm compiler:  
         [0126]    The GNU/ARM executables do not clearly indicate endian-ness. The user is therefore requested to set_tart_endian” before asking the Cobject_file_server to read an object file.  
         [0127]    4. Call an_ofs→read_object_file*( ) with a file name. A non-NULL value should be returned, even if there are errors. If an error has occurred, the OFS will still provide as much info as possible  
         [0128]    Note: do not call read object_file*( ) more than once! An OFS object is intended to be used only once. If you wish to read in another file, you may “new” a new Cobject file server.  
         [0129]    5. Use get_error( ) to see if the read/load succeeded.  
         [0130]    6. You may use an_ofs→get_num_udt( ) and an_ofs→get_udt( ) to simply go thru all of the user defined types. (This is useful for the class browser).  
         [0131]    7. When you are done with the info, you may:  
         [0132]    delete an_ofs;