Apparatus and method for improving performance of critical code execution

Abstract

Critical code routines are identified, separated from other routines, and compiled into a set of one or more critical dynamic link libraries ("DLLs"). These are then recognized by a DLL loader and loaded at a reserved address space in the DLL memory space. Once all of the critical DLLs have been loaded, cache locking may be enabled for the reserved address space. Robust fault containment is facilitated through the use of code modules implemented as shared libraries that can be loaded and unloaded in a running system by individual processes. These code modules can be replaced individually as defects are found and fixed without requiring replacement of the entire system image or application image. What would normally be a monolithic application is modularized, and the sharing of common code among multiple applications is facilitated.

Claims

What is claimed is:

1. A method for improving the performance of critical code execution, comprising:

extracting one or more critical functions from first source files;

creating a critical function source file for each critical function, each of the critical function source files including a corresponding critical function;

creating second source files, each of the second source files including remaining non-critical functions of a corresponding first source file;

generating a pre-load file including a list of the critical functions;

compiling the critical function source files and the second source files into a corresponding set of dynamic link libraries (DLLs) including critical DLLs and and non-critical DLLs; and

loading the critical DLLs and the non-critical DLLs into a memory space at run-time.

2. The method according to claim 1, wherein the critical functions include a packet forwarding algorithm for use in internetworking devices.

3. The method according to claim 1, wherein in said loading the critical DLLs are loaded into the memory space prior to the non-critical DLLs.

4. The method according to claim 1, wherein said loading includes:

parsing the pre-load file to identify the critical DLLs from among the non-critical DLLs.

5. The method according to claim 1, further comprising:

reserving a specific memory space for the critical DLLs.

6. The method according to claim 5, further comprising:

enabling cache locking for the reserved memory space.

7. The method according to claim 6, wherein the critical functions include a packet forwarding algorithm for use in internetworking devices.

8. An apparatus for improving the performance of critical code execution, comprising:

means for extracting one or more critical functions from first source files;

means for creating a critical function source file for each critical function, each of the critical function source files including a corresponding critical function;

means for creating second source files, each of the second source files including remaining non-critical functions of a corresponding first source file;

means for generating a pre-load file including a list of the critical functions;

means for compiling the critical function source files and the second source files into a corresponding set of dynamic link libraries (DLLs) including critical DLLs and non-critical DLLs; and

means for loading the critical DLLs and the non-critical DLLs into a memory space at run-time.

9. The apparatus according to claim 8, wherein the critical functions include a packet forwarding algorithm for use in internetworking devices.

10. The apparatus according to claim 8 wherein said means for loading loads the critical DLLs into the memory space prior to the non-critical DLLs.

11. The apparatus according to claim 8, wherein said means for loading includes:

means for parsing the pre-load file to identify the critical DLLs from among the non-critical DLLs.

12. The apparatus according to claim 8, further comprising:

means for reserving a specific memory space for the critical DLLs.

13. The apparatus according to claim 12, further comprising:

means for enabling cache locking for the reserved memory space.

14. The apparatus according to claim 13, wherein the critical functions include a packet forwarding algorithm for use in internetworking devices.

15. A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for improving the performance of critical code execution, the method comprising:

extracting one or more critical functions from first source files;

creating a critical function source file for each critical function, each of the critical function source files including a corresponding critical function;

creating second source files, each of the second source files including remaining non-critical functions of a corresponding first source file;

generating a pre-load file including a list of the critical functions;

compiling the critical function source files and the second source files into a corresponding set of dynamic link libraries (DLLs) including critical DLLs and non-critical DLLs; and

loading the critical DLLs and the non-critical DLLs into a memory space at run-time.

16. An apparatus, comprising:

a microprocessor, said microprocessor including an instruction cache;

a memory containing a set of dynamic link libraries (DLLs), said DLLs including critical DLLs and non-critical DLLs, each of the critical DLLs including only one critical function, each of the non-critical DLLs including one or more non-critical functions;

a pre-load file comprising a list of the critical DLLs;

a utility for parsing said pre-load file at run-time so as to identify the critical DLLs from among the DLLs; and

a DLL loader cooperative with said utility, for loading the critical DLLs and the non-critical DLLs onto the instruction cache, the critical DLLs being loaded into a specific memory area of the instruction cache reserved for the critical DLLs.

17. The apparatus of claim 16, wherein said apparatus is a data networking device.

18. The apparatus according to claim 17, further comprising logic for enabling cache locking for at least a portion of the instruction cache.

19. The apparatus according to claim 16, further comprising:

logic for enabling cache locking for at least a portion of the instruction cache.

20. The apparatus according to claim 16, wherein the critical DLLs include a packet forwarding algorithm for use in internetworking devices.

21. The apparatus according to claim 20, further comprising logic for enabling cache locking for at least a portion of the instruction cache.

22. An apparatus for improving the performance of critical code execution, comprising:

a critical function extractor for extracting one or more critical functions from first source files;

a source file generator for creating a critical function source file for each critical function, each of the critical function source files including a corresponding critical function, and for creating second source files, each of the second source files including remaining non-critical functions of a corresponding first source file;

a pre-load file generator for generating a pre-load file including a list of the critical functions;

a compiler for compiling the critical function source files and the second source files into a corresponding set of dynamic link libraries (DLLs) including critical DLLs and non-critical DLLs; and

a DLL loader for loading the critical DLLs and the non-critical DLLs into a memory space at run-time.

23. The apparatus according to claim 22, wherein said DLL loader loads the critical DLLs into the memory space prior to the non-critical DLLs.

24. The apparatus according to claim 22, further comprising:

a run-time parsing utility for parsing the pre-load file at run-time to identify the critical DLLs from among the non-critical DLLs.

25. The apparatus according to claim 22, further comprising:

a memory allocator for reserving a specific memory space for the critical DLLs.

26. The apparatus according to claim 25, further comprising:

logic for enabling cache locking for the reserved memory space.

27. The apparatus according to claim 26, wherein said critical code includes a packet forwarding algorithm for use in internetworking devices.

28. The apparatus according to claim 22, wherein said critical code includes a packet forwarding algorithm for use in internetworking devices.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of data communications networks. More particularly, the present invention relates to performance improvement of critical code execution using shared libraries and/or cache locking techniques.

2. Background

FIG. 1 is a block diagram illustrating a network connection between a user 10 and a particular web page 20. FIG. 1 is an example which may be consistent with any type of network known to those skilled in the art, including a Local Area Network ("LAN"), a wide area network ("WAN"), or a combination of networks, such as the Internet.

When a user 10 connects to a particular destination, such as a requested web page 20, the connection from the user 10 to the web page 20 is typically routed through several routers 12A-12D. Routers are internetworking devices. They are typically used to connect similar and heterogeneous network segments into Internetworks. For example, two, LANs may be connected across a dial-up, integrated services digital network ("ISDN"), or across a leased line via routers. Routers may also be found throughout the Internet. End users may connect to a local Internet service provider ("ISP") (not shown).

FIG. 2 is a block diagram of a sample router 12 suitable for implementing an embodiment of the present invention. The router 12 is shown to include a master control processing unit ("CPU") 210, low and medium speed interfaces 220, and high speed interfaces 230. The CPU 210 may be responsible for performing such router tasks as routing table computations and network management. It may include one or more microprocessor integrated circuits selected from complex instruction set computer ("CISC") integrated circuits (such as the Motorola 68040 Microprocessor), reduced instruction set computer ("RISC") integrated circuits (such as the RM4000 or RM7000 RISC processors available from Quantum Effect Design, Inc. of Santa Clara, Calif.), or other available processor integrated circuits. Non-volatile RAM and/or ROM may also form a part of CPU 210. Those of ordinary skill in the art, having the benefit of this disclosure, will recognize that there are many alternative ways in which memory can be coupled to the system.

The interfaces 220 and 230 are typically provided as interface cards. Generally, they control the transmission and reception of data packets over the network, and sometimes support other peripherals used with the router 12. Examples of interfaces that may be included in the low and medium speed interfaces 220 are a multiport communications interface 240, a serial communications interface 250, and a token ring interface 260. Examples of interfaces that may be included in the high speed interfaces 230 include a fiber distributed data interface ("FDDI") 270 and a multiport Ethernet interface 280. Each of these interfaces (low/medium and high speed) may include (1) a plurality of ports appropriate for communication with the appropriate media, and (2) an independent processor such as the 2901 bit slice processor (available from Advanced Micro Devices Corporation of Santa Clara, Calif.) or the RM-7000 RISC processor (available from Quantum Effect Design, Inc. of Santa Clara, Calif.), and in some instances (3) volatile RAM. The independent processors control such communication intensive tasks as packet switching and filtering, and media control and management. By providing separate processors for the communication intensive tasks, this architecture permits the master CPU 210 to efficiently perform routing computations, network diagnostics, security functions, and other similar functions.

The low and medium speed interfaces are shown to be coupled to the master CPU 210 through a data, control, and address bus 290. High speed interfaces 230 are shown to be connected to the bus 290 through a fast data, control, and address bus 292 which is in turn connected to a bus controller 294. The bus controller functions are provided by a processor such as the 2901 bit slice processor or the RM-7000 RISC processor.

Although the system shown in FIG. 2 is an example of a router suitable for implementing an embodiment of the present invention, it is by no means the only router architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. would also be acceptable. Further, other types of interfaces and media could also be used with the router. Moreover, the present invention is not limited to router applications, but may be used in any performance-sensitive application where the execution speed of critical code must be maximized.

In the past, it has not been possible to affect the cache locality of critical code, such as data forwarding or packet switching code in routers. Minor changes made to the code could affect the memory footprint, and hence the caching of critical software forwarding routines. As described herein, newer processors with cache locking functionality offer the ability to lock certain performance-critical routines in cache memory. However, in order to take advantage of cache locking features, a method is needed to guarantee cache locality of critical code.

Thus, the present invention provides consistently faster performance for critical code across software changes and version releases by guaranteeing the cache locality of critical code and by utilizing the cache-locking features of a processor providing such functionality when available. Techniques according to embodiments of the present invention improve the probability that critical code will be cached, and thus offer a significant performance improvement over known techniques. These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and in the associated figures.

SUMMARY OF THE INVENTION

Critical code routines are identified, separated from other routines, and compiled into a set of one or more critical dynamic link libraries ("DLLs"). These are then recognized by a DLL loader and loaded at a reserved address space in the DLL memory space. Once all of the critical DLLs have been loaded, cache locking may be enabled for the reserved address space. Robust fault containment is facilitated through the use of code modules implemented as shared libraries that can be loaded and unloaded in a running system by individual processes. These code modules can be replaced individually as defects are found and fixed without requiring replacement of the entire system image or application image. What would normally be a monolithic application is modularized, and the sharing of common code among multiple applications is facilitated.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the present description, serve to explain the principles of the invention.

In the drawings:

FIG. 1 is a block diagram of an example of a network connection between a user and a web page.

FIG. 2 is a block diagram of a sample router suitable for implementing an embodiment of the present invention.

FIG. 3 is a block diagram illustrating the process of loading a dynamic linked library according to aspects of the present invention.

FIG. 4 is a block diagram illustrating the process of resolving a symbol according to aspects of the present invention.

FIG. 5 is a block diagram illustrating the process of unloading a dynamic linked library according to aspects of the present invention.

FIG. 6 is a block diagram illustrating the use of nested shared libraries according to an aspect of the present invention.

FIG. 7 is a block diagram illustrating an exemplary memory layout on one hardware platform implementation of the present invention.

FIG. 8 is a simplified block diagram of the RM7000 processor used in one embodiment of the present invention.

FIG. 9 is a block diagram of the primary instruction cache organization of the RM7000 processor used in one embodiment of the present invention.

FIG. 10 is a block diagram of the primary instruction cache line format in the RM7000 processor used in one embodiment of the present invention.

FIG. 11 is a block diagram illustrating how the virtual address is divided on an instruction cache access in the RM7000 processor used in one embodiment of the present invention.

FIG. 12 is a simplified block diagram illustrating a set of source files containing a plurality of functions, wherein one or more of those functions are considered to be critical, and wherein the critical functions are separated from the rest of the functions according to aspects of the present invention.

FIG. 13 is a flow chart illustrating the process of tagging and loading portions critical code according to one embodiment of the present invention.

DETAILED DESCRIPTION

Those of ordinary skill in the art, having the benefit of this disclosure, will realize that the following description of the present invention is illustrative only and not in any way limiting. Other embodiments of the invention will readily suggest themselves to such skilled persons after a perusal of the within disclosure.

In the interest of clarity, not all the routine features of the implementations are described. It will of course be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system- and business-related constraints, and that these goals will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill having the benefit of this disclosure.

In the context of the present invention, the term "network" includes local area networks, wide area networks, the Internet, cable television systems, telephone systems, wireless telecommunications systems, fiber optic networks, ATM networks, frame relay networks, satellite communications systems, and the like. Such networks are well known in the art and consequently are not further described here.

One of the design goals of complex software applications is to provide fault containment through the use of code modules that can be loaded and unloaded in a running system by individual processes. These code modules can be replaced individually as defects are found and fixed without replacement of the entire system image or applications. This design goal can be satisfied through the use of shared libraries. Shared libraries allow what would normally be a monolithic application to be modularized and to allow the sharing of common code among multiple applications.

It should be noted that the terms "shared library" and "dynamic link library" are used interchangeably in this document. A Dynamic Link Library ("DLL") represents a very powerful and efficient way for applications to share code and data. A DLL is an executable library module containing functions or resources for use by applications or other DLLs. Unlike typical programs however, DLLs do not have a single entry point. Instead, like libraries, DLLs can have multiple entry points, one for each exported subroutine ("Sub") or function ("Function"). It should also be noted that the term "API" in this document means "Application Programming Interface."

Static linking is known to those skilled in the art as the process of writing one or more modules, and then linking them to create a complete, stand-alone executable program. When a program uses a Sub or Function from a library, a copy of that Sub or Function's code is added to the program's executable file. If two programs are running simultaneously and use the same Sub or Function, there will be two copies of that routine present in memory. It would be more efficient if the two programs could share a single copy of the routine, and DLLs provide that ability.

In contrast to static linking, dynamic linking using DLLs provides a mechanism to link applications to libraries at run-time. Unlike a static library, the code in a DLL is not included into the program that uses the DLL. Instead, a DLL's code and resources are in a separate file (usually with a .DLL extension). This file must be either currently loaded in memory, or accessible to the operating system when the program that uses the DLL executes. To access the individual procedures in a DLL, a DECLARE statement is typically included in the program code with the name of the Sub or Function and the name of the DLL.

Unlike conventional libraries, when a DLL is loaded into memory by the operating system, its procedures are accessible by all other programs (or DLLs). Only one copy of the DLL needs to be present in memory. This is possible because the library is not linked into any one of the programs permanently. It is simply present, in memory, making its services available to any code that may need them.

Before a function or procedure in a DLL can be used, the DLL must first be loaded into memory. Loading DLLs at runtime can be accomplished in two ways: static loading and dynamic loading.

"Static loading" means that a DLL is automatically loaded when the application that calls the DLL is loaded. To use static loading, a function or procedure that resides in the DLL is typically declared with the "external" keyword. The DLL is automatically loaded when the application loads, and any functions or procedures exported from the DLL can then be called just as any other function or procedure would be called. This is by far the easiest way to use code contained in a DLL. The disadvantage to this approach is that if a DLL that the program references is missing, the program will refuse to load.

In contrast, with "dynamic loading," a DLL is only loaded into memory when needed and unloaded from memory when it is no longer needed. One advantage of dynamic DLL loading is that the DLL is in memory only as long as it is needed, resulting in more efficient use of memory. Another advantage is that applications will typically load more quickly when using dynamic loading because not all the code needed to run the program is loaded when the application initially loads.

Shared libraries traditionally use position-independent code ("PIC") (also known as "PC relative addressing") to provide ease of mapping from one process address space to another. The use of PIC allows the code and data in the shared library to be located anywhere within the address space of a given process rather than requiring fixed addresses to be used for each shared library in every process of the system. However, PIC is relatively slower to execute on most processor architectures, due to the additional calculations that must be done during execution to compute the addresses of code and data relative to the program counter ("PC").

As an alternative, absolute addressing ("non-PIC") may be used in the shared libraries. Non-PIC shared libraries provide better performance than PIC shared libraries, but restrict implementation flexibility by requiring that the code and data be located at fixed addresses in the virtual memory space of every process in the system in order to function correctly. This constraint requires the use of a reserved memory region in the virtual address space, so that each process can be guaranteed to not allocate addresses in a shared library region for purposes other than accessing a particular shared library. This constraint also requires additional processing when loading a shared library into memory, as the shared library loader needs to perform address relocations on every explicit address reference. This additional processing will impact the load time for the first process which requests access to a shared library. However, since the additional processing need only be performed once, at the time of loading, subsequent access requests do not incur any load time performance penalty. To optimize performance, one embodiment of the present invention implements non-PIC DLL style shared libraries. However, PIC DLL style shared libraries can also be implemented by those skilled in the art without departing from the scope of the present invention.

Functional Description

The following tables (Tables 1 through 6) identify and describe the software modules used in one embodiment of the present invention. In this embodiment, there are two principal functional components of the present invention: the application program which is to be optimized, and a DLL Manager. Table 1 identifies and describes the DLL Manager source components that are platform independent (i.e., that are not a function of the specific processor used to implement the present invention).

                             TABLE 1
                  DLL Manager source components
    dllmgr.h           Private header. Defines the location and size of
                       the reserved memory region for DLLs, prototepes
                       for DLL Manager functions, and private data
                       types.
    dllmgr_cache.c     Functions to manipulate the DLL handle cache.
    dllmgr_funcs.c     Platform-independent message handling functions
                       (e.g., _DLL_OPEN,_DLL_CLOSE).
    dllmgr_init.c      Functions to initialize the DLL Manager.
    dllmgr_io.c        Functions to handle input/output function
                       messages sent to the DLL Manager.
    dllmgr_search.c    Functions to perform file system searches/
                       "lookups" for shared libraries.
    main.c             Main program for the DLL Manager.
    include/sys/dll_msg.h Public header containing definitions of
                       dllmgr messages and structures.

                             TABLE 2
         DLL Manager platform-dependent source components
        mips/dllmgr_mips.c Functions to perform loading, relocation,
                           and unloading of DLLs for MIPS platforms.
        x86/dllmgr_x86.c   Functions to perform loading, relocation,
                           and unloading of DLLs for x86 platforms.

                             TABLE 3
            Dynamic-linking library source components
        dl_priv.h       Header defining private function prototypes
                        and constants used internally
        dladdr.c        Implementation of dladdr()
        dlclose.c       Implementation of dlclose()
        dlerror.c       Implementation of dlerror()
        dlopen.c        Implementation of dlopen()
        dlsym.c         Implementation of dlsym()
        dlutil.c        Private utility functions used within libdl.a
        include/dlfcn.h Public header defining dynamic-linking library
                        API and data structure definitions

                             TABLE 4
            Minimal static C library source components
    _CMain.c    Secondary application startup routine, called by _start. This
                module has been modified to load the DLL for libc and set
                up various global data before calling the application's
                main().
    exit.c      Application termination function. This module has been
                modified to unload the libc DLL before terminating the
                application.
    init-globals.c Initialize critical libc globals

                             TABLE 5
                   Build host binary components
    libdl.a   This is the dynamic-linking (dl) static library. Each
              application which needs to reference shared libraries
              during its run-time must link with this library in
              addition to any other libraries it may link with.
    libcmin.a This library contains the minimal static libc functions that are
              used in conjunction with the dynamic-linking library for
              applications. It implements only the bare essentials of libc that
              are required for the dynamic-linking library to load the C
              library DLL (libc.dll).
    libc.dll.a This is the stub library used to link with the dynamically
              linked C library (libc.dll). An application using the
              libc DLL will link with this library in addition to the
              libdl.a and libcmin.a static libraries and any other
              application specific libraries.
    mkstubs   This utility is used to generate stubs for Callng DLL functions
              and accessing data components in DLLs.

                             TABLE 6
                    Target platform components
    dllmgr    The module is the DLL Manager (also known as the "DLL
              Loader"). The DLL Manager handles all loading and
              unloading of DLLs in one embodiment of the present
              invention.
    dlladmin  This is the DLL Manager Administration Utility. It
              communicates with the DLL Manager to change the run-time
              behavior of the DLL Manager, retrieve status of DLLs
              currently loaded in the system, and may be used to verify or
              validate a DLL before it is loaded into the running system.
    libc.dll  This is the shared C library. It is loaded on behalf of
              applications by the DLL Manager (dllmgr).

    Usage:  dllmgr [options] &
    Options:
    -d mask   This option specifies the debug level. Used to direct dllmgr to
              emit information during operation. Debug masks are
              defined in dlfcn.h
    -v        This option specifies verbose mode. In this mode, dllmgr will
              print various ongoing status messages to the system console.
    -u seconds Specifies the numbers of seconds before an unreferenced
              DLL will be considered for removal from memory.
    -r seconds Specifies the delay time between scans for unreferenced
              DLLs.
    -p        Directs the dllmgr to use private TLB mappings when loading
              DLLs rather than placing the text segment into a global TLB
              mapping.

    Usage:  dlladmin [options]
    Options:
    -v            Verbose mode. Emits additional information during
                  command processing.
    -i DLL/all    Report information about the specified DLL. The
                  reserved keyword all specifies that information
                  about all loaded DLLs will be reported.
    -1 DLL        Load specified DLL into memory.
    -u DLL        Unload specified DLL. If the specified DLL is not
                  referenced by any running application, it will be
                  unloaded immediately. Otherwise, the request to
                  unload will be queued and the actual unloading of
                  the DLL will happen when the last application
                  releases its reference to the DLL (via dlclose()).
    -w DLL        "Wire" the specified DLL in memory (forces DLL
                  to stay resident even when there are no more references).
    -c chksum DLL Validate DLL against specified checksum.

    Usage:  mkstubs [options] outputlibrary g0library [g0libs]
    Options:
    -a arch       Architecture to be used
    -D directory  Directory to place generated stubs
    -d libname.dll DLL library the stubs are to reference
    -h            Print the usage message
    -k            Keep generated source files (default when -S is specified)
    -p prefix     Specifies prefix for generated source file names
    -S            Generate stub source files only (don't compile/build
                  library)
    -s suffix     Suffix for generated source file names
    -v            Be verbose and print status/info messages during stub
                  generation
    outputlibrary Specifies library where generated .o files should be
                  placed
    g0library     Specifies library used as the source for collecting symbol
                  names to be used as stubs
    [g0libs]      Additional libraries or .o files to be scanned for stub
                  symbols

    #   /* This file was automatically generated by /router/bin/mkstubs */
    #   #include <dlfcn.h>
    #   dll_t *_libtest1_dllhandle = NULL;
    #   void *
    #   _libtest1_dllload (char *sym, void **addr)
    #   {
    #       if ( _libtest1_dllhandle == NULL)
    #           _libtest1_dllhandle =
     dlopen(.backslash."libtest1.dll.backslash.", 0);
    #       if ( _libtest1_dllhandle != NULL)
    #           *addr = dlsym(_libtest1_dllhandle, sym);
    #       return (*addr);
    #   }
        .glob1  _libtest1_dllhandle
        .data
        .align 2
    _libtest1_dllhandle:
        .word 0
        .rdata
        .align 2
    _libtest1_libname:
        .ascii "libtest1.dll.backslash.000"
        .text
        .set noreorder
        .align 2
        .globl _libtest1_dllload
        .ent _libtest1_dllload
    _libtest1_dllload:
        .frame  $sp,44,$31           #   vars= 0, regs= 4/0, args= 16,
        extra=  0
        .mask   0x800300f0,-8        #   mask for ra,s1,s0,a3,a2,a1,a0
        .fmask  0x00000000,0
        lw      $2,_libtest1_dllhandle
        subu    $sp,$sp,44           #   adjust the stack
        sw      $4,16($sp)           #   save the first arg
        sw      $5,20($sp)           #   save the second arg
        sw      $6,24($sp)           #   save the third arg
        sw      $7,28($sp)           #   save the fourth arg
        sw      $31,32($sp)          #   save the return address
        sw      $16,36($sp)          #   save original s0
        sw      $17,40($sp)          #   save original s1
        move    $16,$8               #   save the sym arg
        bne     $2,$0,_libtest1_loaded #   if dllhandle != NULL
        move    $17,$9               #   save the addr arg (delay slot)
        la      $4,_libtest1_libname #   a0 <- library name
        jal     dlopen               #   handle = dlopen(library, 0)
        move    $5,$0                #   a1 <- 0 (branch delay slot)
        sw      $2,_libtest1_dllhandle
        beq     $2,$0,_libtest1_havesym #   if handle == 0
        nop                          #   branch delay slot
        .end    _libtest1_dllload
        lw      $7,28($sp)           #   save the fourth arg
        lw      $16,36($sp)          #   restore s0
        lw      $17,40($sp)          #   restore s1
        lw      $31,32($sp)          #   restore ra
        j       $2                   #   make the call (or call NULL)
        addu    $sp,$sp,44           #   fix the stack
        .end    _libtest1_havesym
        .set    reorder

    gcc.96ql.mips64 -r -u -start -u main -EB -G 4 -u_start -e_start -
    nostdlib -o/ /aaf/user/dllmgr/test/testdll/mips/dlllinked/testdll.tmp -g
    testdll.o -L. -L/aaf/user/support/mipsbe/lib -L/aaf/user/usr/mipsbe/lib
    -Wl,--whole--archive -ldl

    gcc.96ql.mips64 -nostdlib -T/aaf/user/usr/mipsbe/etc/ link.map -Ttext
    0x8020000 /user/usr/mipsbe/lib/ crtl.o -mips2 --no-keep-memory -
    o/aaf/user/dllmgr/ test/testdll/mips/dlllinked/testdll
    /user/dllmgr/test/testdll/mips/dlllinked/testdll.tmp -g -L. -
    L/aaf/user/support/mipsbe/lib -L/aaf/user/usr/mipsbe/lib -lcmin -
    ltest1.dll -ltest2.dll -EB -lc.dll -lsoftfp -lgcc_math

    gcc.96ql.mips64 -r -u -start -u main -EB -G 0 -u_start -e_start -
    nostdlib -Wl, -Map -Wl,libtest1.dll.sym.tmp.map -o libtest1.dll.sym.tmp
    -T/aaf/user/usr/mipsbe/etc/link. map -Ttext 0x0 .sub.---- get_errfoo_ptr.o
    dllmain.o func1.o func2.o func3.o unload_test2.o --whole-archive -
    L/aaf/user/usr/mipsbe/lib -ldl
    gcc.96ql.misp64 -r -u_start -u main -EB -G 0 -u_start -e_start -nostdlib
    -Wl,-Map -Wl,libtest1.dll.sym.map -e dllmain -o libtest1.dll.sym -
    T/aaf/user/usr/mipsbe/etc/link.map -Ttext 0x0 libtest1.dll.sym.tmp -
    L/aaf/user/usr/mipsbe/lib -lcmin -lsoftfp -lgcc_math -lc.dll
    gcc.96ql.misp64 -r -u_start -u main -EB -G 0 -u_start -e_start -nostdlib
    -Wl, -Map -Wl,libtest1.dll.map.tmp -o /aaf/user/dllmgr/test/
    libtest1/mips/dll.be/libtest1.dll.tmp .sub.---- get_errfoo-ptr.o dllmain.o
    func1.o func2.o func3.o unload_test2.o --whole-archive
    /aaf/user/usr/mipsbe/lib/libdl.a
    gcc.96ql.misp64 -r -u_start -u main -EB -G 0 -u_start -e_start -nostdlib
    -Wl,-Map -Wl.libtest1.dll.map -o
    /aaf/user/dllmgr/test/libtest1/mips/dll.be/libtest1.dll
    /aaf/user/dllmgr/test/libtest1/mips/dll.be/libtest1.dll.tmp -
    L/aaf/user/usr/mipsbe/lib -lcmin -lsoftfp -lgcc_math -lc.dll

                             TABLE 7
                      Cache Locking Control
              Lock                                     How to
    Cache     Enable    Set Select                     Activate
    Primary   ECC[27]   ECC[28]=0 -> A ECC[28]=1 -> B CACHE
    Instruction                                          Fill_I
    Primary   ECC[26]   ECC[28]=0 -> A ECC[28]=1 -> B Load/
    Data                                               Store
    Secondary ECC[25]   ECC[28]=0 -> A ECC[28]=1 -> B CACHE
                                                       Fill_I
                                                       or
                                                       Load/
                                                       Store

    1i      r1,LOCK_ICACHE .vertline. LOCK_SET0 #setup set 0 for locking
    mtc0    r1,C0_ECC
    nop
    nop
    cache   Fill_I,0(r10)                  #lock this code
    nop
    nop
    mtc0    r0,C0_ECC                      #next instr fetch not
                                           locked

• Inventors
  Moberg, Kenneth; Stine, Arthur B.; Kon, Ronnie Bernard;
• Assignee
  Cisco Technology, Inc. (San Jose, CA)
• Published
  Feb-24-2004
• Current US Classes:
  717/141
  717/154
  717/166
• Application #
  594179
• International Classes
  G06F 009/45; G06F 009/44
• Field of Search
  717/140-143 717/151-152 717/154 717/158 717/162-164 717/166-167 709/212-219 709/227 709/237-238 709/249
• Examiner
  Nguyen-Ba; Antony
• Agent
  Thelen Reid & Priest, LLP, Ritchie; David B.
• US Patent References:
  5243596
  5493667
  5787470
  6064406
  6158049
  6223256
  6289506
  6298370
  6421703
  6453404