WO2018137258A1

WO2018137258A1 - Loadable modules with partial linking and load-time relocation

Info

Publication number: WO2018137258A1
Application number: PCT/CN2017/072788
Authority: WO
Inventors: Zhi Chen; Yusheng Yang
Original assignee: Qualcomm Incorporated
Priority date: 2017-01-30
Filing date: 2017-01-30
Publication date: 2018-08-02

Abstract

A loadable module design that can be implemented in hardware-limited platforms. In particular, according to various aspects, literal memory space (424) may be reserved to the loadable module on a processor (610) running in an absolute addressing mode, wherein the literal space (424) may be reserved in a valid address range accessible to one or more address-restricted instructions. At build time, a partial linking combining one or more object files (320, 322, 324) associated with the loadable module with operating system exported symbols (330) may be generated. Accordingly, at load time, literal space may be allocated to the loadable module from the reserved literal memory space (424) and text and data spaces may be allocated from unused memory (440) such that addresses associated with all internal functions and variables may be relocated according to start addresses associated with the literal, text, and data spaces.

Description

LOADABLE MODULES WITH PARTIAL LINKING AND LOAD-TIME RELOCATION

TECHNICAL FIELD

The various aspects and embodiments described herein generally relate to a loadable module design that can be implemented in hardware-limited platforms.

BACKGROUND

Loadable module is a technology extensively used in designing software modules and device drivers. In general, loadable modules provide a flexible way to design software and reduce memory size requirements. For example, a loadable module generally refers to an object file that contains code to extend a running kernel (or base kernel) associated with an operating system. Accordingly, loadable modules may be used to define device drivers to support new hardware, to support new filesystems, and add system calls that allow applications running in an unprivileged or restricted mode to request a service from the operating system kernel, among other things. Loadable modules therefore offer various advantages, including that operating systems lacking loadable module support would be required to have all possible functionality compiled directly into the base kernel, which would waste memory because substantial unused functionality would reside in memory. In contrast, when functionality associated with a loadable module is needed, the loadable module can be dynamically loaded into memory and later unloaded to free memory and other resources when not needed.

Despite the various advantages that loadable module technology can offer, there are some computing platforms that are unable to use loadable modules. For example, hardware-limited platforms with small memory size (e.g., Internet of Things (IoT) devices) may have processors that lack a memory management unit (MMU) . Consequently, difficulties may arise with respect to managing memory allocations associated with loadable modules because all memory access instructions have to use absolute addresses. Furthermore, in processors that use absolute memory addresses, at least some instructions may only have the ability to access a restricted memory range, which means that the compiler may be unable to generate position-independent code that can be executed at any memory address regardless of the absolute address. Indeed, some compilers that are configured to generate position-independent code do not permit absolute addresses to be used because position-independent code has to use relative addressing. Furthermore, implementing loadable modules may be difficult in platforms in which the operating system and applications are compiled together as one binary image because the symbol table is typically stripped from the binary image, meaning that there is no symbol information at run-time.

Accordingly, based on at least the foregoing, there is an apparent need to provide mechanisms to implement loadable modules in hardware-limited platforms.

SUMMARY

The following presents a simplified summary relating to one or more aspects and/or embodiments disclosed herein. As such, the following summary should not be considered an extensive overview relating to all contemplated aspects and/or embodiments, nor should the following summary be regarded to identify key or critical elements relating to all contemplated aspects and/or embodiments or to delineate the scope associated with any particular aspect and/or embodiment. Accordingly, the following summary has the sole purpose to present certain concepts relating to one or more aspects and/or embodiments relating to the mechanisms disclosed herein in a simplified form to precede the detailed description presented below.

According to various aspects, a method for implementing a loadable module may comprise reserving literal memory space to the loadable module on a processor running in an absolute addressing mode, generating a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols, and allocating literal space to the loadable module from the reserved literal memory space to initialize the loadable module.

According to various aspects, an apparatus may comprise a memory comprising at least an instruction random access memory (RAM) and a processor configured to reserve literal memory space to a loadable module running in an absolute addressing mode, generate, via a linking tool, a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols, and allocate literal space to the loadable module from the reserved literal memory space to initialize the loadable module.

According to various aspects, an apparatus may comprise means for reserving literal memory space to a loadable module configured to run in an absolute addressing mode, means for generating a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols, and means for allocating literal space to the loadable module from the reserved literal memory space to initialize the loadable module.

According to various aspects, a computer-readable medium may store computer-executable instructions, which may be configured to cause one or more processors to reserve literal memory space to a loadable module configured to run in an absolute addressing mode, generate a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols, and allocate literal space to the loadable module from the reserved literal memory space to initialize the loadable module.

Other objects and advantages associated with the aspects and embodiments disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the various aspects and embodiments described herein and many attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings which are presented solely for illustration and not limitation, and in which:

FIG. 1 illustrates an exemplary layered computer architecture in which in which loadable modules as described herein may be implemented, according to various aspects.

FIG. 2 illustrates an exemplary memory space reservation that can be used to implement a loadable module as described herein, according to various aspects.

FIG. 3 illustrates an exemplary design approach to generate a loadable module with a partial linking as described herein, according to various aspects.

FIG. 4 illustrates an exemplary load-time memory relocation that can be used to implement a loadable module as described herein, according to various aspects.

FIG. 5 illustrates an exemplary method to implement a loadable module with partial linking and load-time relocation as described herein, according to various aspects.

FIG. 6 illustrates an example electronic device in which loadable modules as described herein may be advantageously implemented.

DETAILED DESCRIPTION

Various aspects and embodiments are disclosed in the following description and related drawings to show specific examples relating to exemplary aspects and embodiments. Alternate aspects and embodiments will be apparent to those skilled in the pertinent art upon reading this disclosure, and may be constructed and practiced without departing from the scope or spirit of the disclosure. Additionally, well-known elements will not be described in detail or may be omitted so as to not obscure the relevant details of the aspects and embodiments disclosed herein.

The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Likewise, the term “embodiments” does not require that all embodiments include the discussed feature, advantage, or mode of operation.

The terminology used herein describes particular embodiments only and should not be construed to limit any embodiments disclosed herein. As used herein, the singular forms “a, ” “an, ” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Those skilled in the art will further understand that the terms “comprises, ” “comprising, ” “includes, ” and/or “including, ” as used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Further, various aspects and/or embodiments may be described in terms of sequences of actions to be performed by, for example, elements of a computing device. Those skilled in the art will recognize that various actions described herein can be performed by specific circuits (e.g., an application specific integrated circuit (ASIC)) , by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequences of actions described herein can be considered to be embodied entirely within any form of non-transitory computer-readable medium having stored thereon a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects described herein may be embodied in a number of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the aspects described herein, the corresponding form of any such aspects may be described herein as, for example, “logic configured to” and/or other structural components configured to perform the described action.

According to various aspects, FIG. 1 illustrates an exemplary layered computer architecture 100 in which in which loadable modules as described herein may be implemented. In general, the layered computer architecture 100 shown in FIG. 1 includes various logical components and interfaces to explain certain aspects associated with the loadable module design approach described herein. As such, those skilled in the art will appreciate that the present disclosure contemplates that various changes may be made to the architecture 100 as shown in FIG. 1 and that certain details that are not germane to the loadable module design approach described herein may be omitted for clarity.

According to various aspects, as shown in FIG. 1, the example architecture 100 includes both hardware components and software components, wherein the hardware components generally include physical memory 104, input/output (I/O) devices 106, and execution hardware 102 (e.g., an application processor, a digital signal processor, etc. ) . The software components may include an operating system 112, a libraries module 122, and one or more application programs 132. Accordingly, the application programs 132 generally use an application program interface (API) 130 to issue library calls to the libraries module 122, which may use an application binary interface (ABI) 120 to invoke services on the operating system 112 (e.g., via system calls) . The operating system 108 therefore runs instructions in supervisor mode to communicate with the hardware components using a specific instruction set architecture (ISA) 110, which may include specific operation codes (opcodes) and native commands implemented on the execution hardware 102. The ABI 120 defines the machine as seen from the perspective of the application program processes, whereas the API 132 specifies the machine characteristics as seen from the perspective of a high-level language program and the ISA 110 defines the machine as seen from the perspective of the operating system 112. In various embodiments, the software components may be further divided into a kernel space and a user space to provide hardware protection from malicious or unexpected software behavior, to allow different instructions to execute with different privilege levels, etc.

According to various aspects, the architecture 100 as shown in FIG. 1 may support loadable modules that are often used to design software and reduce memory requirements. For example, in FIG. 1, the operating system 112 may include a base kernel and provide support to dynamically load and unload one or more loadable modules to extend the base kernel. In that sense, loadable modules offer the ability to define device drivers to support new I/O devices 106 or other hardware, to support new filesystems, and add system calls that allow application programs 132 running in an unprivileged or restricted mode to request a service from the operating system 112 without requiring that functionality to be directly linked within the base kernel when the operating system 112 is compiled. Loadable modules therefore offer various advantages, including that certain functionality can be excluded from the base kernel, which may improve memory efficiency. Furthermore, loadable modules are well-suited to defining device drivers because the base kernel can communicate with the underlying hardware without having to know how the hardware works and without requiring every driver to be built into the base kernel.

Although loadable modules have various advantageous aspects, loadable modules are not easily implemented in all computing platforms. For example, in certain hardware-limited computing platforms (e.g., Internet of Things (IoT) devices) , the memory 104 may have a small size and processors or other execution hardware 102 may lack a memory management unit (MMU) . Consequently, difficulties may arise with respect to managing memory allocations associated with loadable modules in memory-constrained platforms where memory access instructions use absolute addresses. Furthermore, in processors that use absolute memory addresses, at least some instructions may only have the ability to access a restricted memory range, which means that the compiler may be unable to generate position-independent code that can be executed at any memory address regardless of the absolute address. Furthermore, implementing loadable modules may be difficult in platforms in which the operating system 112 and applications 132 (and/or libraries 122) are compiled together as one binary image because the symbol table may be stripped from the binary image, meaning that there is no symbol information at run-time.

As such, according to various aspects, the following description provides a design approach that can be used to implement loadable modules in these hardware-limited platforms. However, those skilled in the art will appreciate that the loadable module design approach described herein may be suitably applied in other platforms that may or may not be considered hardware-limited, memory-constrained, etc. In particular, as will be described in further detail below, the loadable module design approach may include a memory space reservation to support instructions that may only have the ability to access a restricted memory range, a compile-time partial linking, and a load-time relocation.

According to various aspects, FIG. 2 illustrates an exemplary memory space reservation 200 that can be used to implement a loadable module in a platform that includes one or more instructions that can only access a restricted memory range. In general, FIG. 2 illustrates an exemplary instruction random access memory (RAM) 210, which may provide an internal read-write instruction memory on a processor. For example, in various embodiments, the instruction RAM 210 may be used (or useful) when all the code to run a particular application can fit within a small memory such that a separate instruction cache may not be necessary. Alternatively, the instruction RAM 210 could be used as an additional instruction store in parallel with the instruction cache to store instructions associated with code that requires constant access time.

In various embodiments, the instruction RAM 210 may be provided on a processor (not explicitly shown) that can run in an “absolute” mode in which all memory accesses use absolute addresses (or specific addresses) as distinct from relative addresses that specify a memory location relative to some base address. Furthermore, the ISA may include one or more absolute address related instructions that cannot access all memory locations. For example, in the ISA associated with the

processor, the instruction “L32R” can only access a 256KB memory space that starts at a literal base address 220. Accordingly, in the memory space reservation 200 shown in FIG. 2, the instruction RAM 210 may include a valid address-restricted range 226 with a first space 222 allocated to operating system and application literals. In particular, as used herein, the term “literal” and variants thereof may generally refer to a source code notation used to represent a fixed value (e.g., atomic integer values, floating-point numbers, strings, etc., in contrast to variables or constants that are symbols that can take on a literal value) . To ensure that literals associated with loadable modules are stored within memory locations that any address-restricted instructions can suitably access, the memory space reservation 200 may reserve literal memory space 224 to the loadable module (s) within the address-restricted instruction range 226 while compiling the operating system and application (s) into a binary image. Accordingly, the reserved literal memory space 224 may be dedicated to storing data associated with any literals that may be defined in the loadable module (s) , whereby absolute address related instructions permitted to access the instruction RAM 210 may be guaranteed the ability to reach any memory locations that store literals associated with the operating system, applications, and any loadable modules dynamically loaded at run-time. Outside the valid address-restricted range 226, the instruction RAM 210 may include a space 230 allocated to operating system and application text (e.g., the executable object code) and an unused portion 240 that may dynamically allocated to text or executable object code associated with the loadable modules, as described below.

According to various aspects, FIG. 3 illustrates an exemplary design approach 300 to generate a loadable module with a partial linking as described herein. In particular, the loadable module may generally be defined in one or more source files 310, 312, 314, which may be suitably compiled into corresponding object files 320, 322, 324 using any suitable known or future-developed technique (s) . The object files 320, 322, 324 may be provided to a linking tool 340 along with any operating system and application exported symbols 330. At build time, the linking tool 340 may be configured to generate a partial linking that combines the loadable module object files 320, 322, 324 and the operating system and application exported symbols 330. For example, the linking tool 340 may be the “ld” command line utility, which may generate a partial linking when invoked with the optional “-r” (or “relocatable output) parameter. As such, when configured to generate a partial linking, the output from the linking tool 340 may be an output file that can in turn serve as an input to the linking tool 340. In various embodiments, the partial linking may be used to output a loadable module object file 350 in which all external symbols (e.g., the operating system and application exported symbols 330) are linked as absolute addresses. In various embodiments, the loadable module object file 350 may be generated according to the Executable and Linkable Format (ELF) standard binary file format supported on many different operating systems and platforms.

According to various aspects, an exemplary load-time memory relocation 400 that can be used to implement a loadable module as described herein will now be described with reference to FIG. 4. More particularly, the load-time memory relocation 400 as shown in FIG. 4 may generally be carried out on a processor configured to run in an absolute mode in which all memory access instructions use absolute addresses and one or more applications are compiled together with an operating system as one binary image with a symbol table stripped from the binary image. As shown in FIG. 4, an instruction RAM 410 may include an operating system and application literal space 422 and a loadable module reserved literal space 424, which may collectively span a valid range that one or more address-restricted instructions can access. Furthermore, the instruction RAM 430 may include space allocated to operating system and application text (e.g., executable object code) . In various embodiments, at load-time, management code built into the operating system may dynamically load one or more loadable modules into the instruction RAM 410. Accordingly, as shown in FIG. 4, the operating system may allocate literal space 426 to the loadable module from the reserved literal space 424. Furthermore, the operating system may allocate text space 442 to the loadable module from the unused portion 440 in the instruction RAM 410 and further allocate data space 466 to initialized data associated with the loadable module from unused space 470 in a data RAM 450. In The operating system and application may be allocated data space 462 in the data RAM 450 and one or more dynamic buffers 464 may be further allocated in the data RAM 450.

In various embodiments, a relocation may then be performed to calculate and patch addresses associated with all internal functions and all internal variables associated with the loadable module according to the start addresses associated with the loadable module text segment 442 and the loadable module data segment 466. Furthermore, one or more absolute address related instructions (e.g., “L32R” ) may be patched with the address associated with the loadable module literal segment 426. Accordingly, the loadable module literal segment 426, the loadable module text segment 442, and the loadable module data segment 466 may collectively represent the dynamically relocated segments 480 associated with the loadable module, which are allocated among the instruction RAM 410 and the data RAM 450 as shown in FIG. 4. In various embodiments, the “init” function associated with the loadable module may then be executed to start the loadable module, and at some future point in time, the “exit” function may be executed to start an unloading stage. Accordingly, after the “exit” function is executed, the loadable module literal segment 426, the loadable module text segment 442, and the loadable module data segment 466 may be released from the instruction RAM 410 and the data RAM 450.

According to various aspects, FIG. 5 illustrates an exemplary method 500 to implement a loadable module with partial linking and load-time relocation as described herein. In particular, at block 510, literal space may be reserved to the loadable module while compiling an operating system binary image. For example, in various embodiments, the literal space may be reserved in an instruction RAM within a valid range accessible to one or more absolute address related instructions. According to various aspects, at block 520, a partial linking that combines one or more object files associated with the loadable module and any operating system and application exported symbols may be generated. For example, the partial linking generated at block 520 may be an output file that can in turn serve as an input to a linking tool or utility that generated the partial linking, which may link all external symbols as absolute addresses.

According to various aspects, the memory space reservation and the partial linking may thereby enable an operating system to dynamically load and unload the loadable module at run-time. More particularly, at block 530, the operating system may allocate literal space to the loadable module from the literal space that was reserved at block 510, while text and data spaces may be allocated from unused space in an instruction RAM and a data RAM, respectively. At block 540, addresses associated with all internal functions and all internal variables associated with the loadable module may be calculated and patched according to the start address associated with the literal, text, and data segments allocated to the loadable module. Furthermore, one or more absolute address related instructions may be patched with the address associated with the literal segment allocated to the loadable module. Accordingly, at block 550, a function to initialize the loadable module may be executed to start the loadable module, and at some future point in time, a function to exit or otherwise terminate the loadable module may be executed. After the exit function has been executed, the operating system may release the literal, text, and data segments allocated to the loadable module at block 560.

According to various aspects, FIG. 6 illustrates an example electronic device 600 that may advantageously implement loadable modules with partial linking and load-time relocation as described in further detail above with reference to FIG. 1 through FIG. 5. In various embodiments, the electronic device 600 may be configured as a wireless device. As shown in FIG. 6, the electronic device 600 may include a processor 610, which can be a digital signal processor (DSP) or any general purpose processor or central processing unit (CPU) as known in the art, for example. In various embodiments, the processor 610 may include an instruction random access memory (RAM) 410 and a data RAM 450 that are configured to store various dynamically relocated segments associated with a loadable module as described in further detail above with reference to FIG. 4. Furthermore, according to various embodiments, the processor 610 may be configured to implement at least blocks 530-560 in the method 500 shown in FIG. 5 and described in further detail above. As further shown in FIG. 6, the processor 610 may include and/or be communicatively coupled to a memory 650, which may comprise one or more caches or other memory structures as described herein.

According to various embodiments, FIG. 6 also shows that the electronic device 600 may include a display controller 626 coupled to the processor 610 and to a display 628. The electronic device 600 may further include a coder/decoder (CODEC) 634 (e.g., an audio and/or voice CODEC) coupled to processor 610. Other components, such as a wireless controller 640 (e.g., a modem) are also illustrated in FIG. 6. In various embodiments, a speaker 636 and a microphone 638 can be coupled to the CODEC 634. Furthermore, as shown in FIG. 6, the wireless controller 640 can be coupled to a wireless antenna 642. According to various aspects, the processor 610, the display controller 626, the memory 650, the CODEC 634, and/or the wireless controller 640 may be provided in a system-in-package or a system-on-chip device 622.

In various embodiments, an input device 630 and a power supply 644 may be coupled to the system-on-chip device 622. Moreover, as illustrated in FIG. 6, the display 628, the input device 630, the speaker 636, the microphone 638, the wireless antenna 642, and the power supply 644 are shown as being external to the system-on-chip device 622. However, those skilled in the art will appreciate that the display 628, the input device 630, the speaker 636, the microphone 638, the wireless antenna 642, and/or the power supply 644 can be coupled to a component associated with the system-on-chip device 622 (e.g., via an interface or a controller) . Furthermore, although FIG. 6 depicts the electronic device 600 as a wireless communications device, those skilled in the art will appreciate that the various components illustrated in FIG. 6 may be integrated into a set top box, a music player, a video player, an entertainment unit, a navigation device, a personal digital assistant (PDA) , a fixed location data unit, a computer, a laptop, a tablet, a communications device, a mobile phone, etc.

Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Further, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted to depart from the scope of the various aspects and embodiments described herein.

The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration) .

The methods, sequences, and/or algorithms described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable medium known in the art. An exemplary non-transitory computer-readable medium may be coupled to the processor such that the processor can read information from, and write information to, the non-transitory computer-readable medium. In the alternative, the non-transitory computer-readable medium may be integral to the processor. The processor and the non-transitory computer-readable medium may reside in an ASIC. The ASIC may reside in an IoT device. In the alternative, the processor and the non-transitory computer-readable medium may be discrete components in a user terminal.

In one or more exemplary aspects, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. Computer-readable media may include storage media and/or communication media including any non-transitory medium that may facilitate transferring a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. The term disk and disc, which may be used interchangeably herein, includes CD, laser disc, optical disc, DVD, floppy disk, and Blu-ray discs, which usually reproduce data magnetically and/or optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

While the foregoing disclosure shows illustrative aspects and embodiments, those skilled in the art will appreciate that various changes and modifications could be made herein without departing from the scope of the disclosure as defined by the appended claims. Furthermore, in accordance with the various illustrative aspects and embodiments described herein, those skilled in the art will appreciate that the functions, steps, and/or actions in any methods described above and/or recited in any method claims appended hereto need not be performed in any particular order. Further still, to the extent that any elements are described above or recited in the appended claims in a singular form, those skilled in the art will appreciate that singular form (s) contemplate the plural as well unless limitation to the singular form (s) is explicitly stated.

Claims

A method for implementing a loadable module, comprising:

reserving literal memory space to the loadable module on a processor running in an absolute addressing mode；

generating a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols； and

initializing the loadable module, wherein the initializing at least comprises allocating literal space to the loadable module from the reserved literal memory space.
The method recited in claim 1, wherein the literal space is reserved in a valid address range accessible to one or more address-restricted instructions.
The method recited in claim 1, wherein the literal space is reserved while compiling an operating system binary image.
The method recited in claim 1, wherein the absolute addressing mode requires all memory access instructions to use absolute memory addresses.
The method recited in claim 1, wherein generating the partial linking comprises linking symbols external to the loadable module as absolute memory addresses.
The method recited in claim 1, wherein the partial linking is generated via a linking tool, and wherein the partial linking comprises a relocatable output that can serve as an input to the linking tool.
The method recited in claim 1, wherein the partial linking comprises an Executable and Linkable Format (ELF) object file.
The method recited in claim 1, wherein the initializing further comprises:

allocating a text space to the loadable module from unused space in an instruction random access memory (RAM) ；

allocating a data space to the loadable module from unused space in a data RAM； and

relocating addresses associated with each internal function and each internal variable associated with the loadable module according to start addresses associated with the literal space, the text space, and the data space allocated to the loadable module.
The method recited in claim 8, further comprising:

releasing the literal space, the text space, and the data space allocated to the loadable module in response to executing a function to unload the loadable module.
An apparatus, comprising:

a memory comprising at least an instruction random access memory (RAM) ； and

a processor configured to reserve literal memory space to a loadable module running in an absolute addressing mode, generate, via a linking tool, a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols, and allocate literal space to the loadable module from the reserved literal memory space to initialize the loadable module.
The apparatus recited in claim 10, wherein the literal space is reserved in a valid address range accessible to one or more address-restricted instructions.
The apparatus recited in claim 10, wherein the literal space is reserved while compiling an operating system binary image.
The apparatus recited in claim 10, wherein the absolute addressing mode requires all instructions that access the memory to use absolute memory addresses.
The apparatus recited in claim 10, wherein the partial linking is configured to link symbols external to the loadable module as absolute memory addresses.
The apparatus recited in claim 10, wherein the partial linking comprises a relocatable output that can serve as an input to the linking tool.
The apparatus recited in claim 10, wherein the partial linking comprises an Executable and Linkable Format (ELF) object file.
The apparatus recited in claim 10, wherein the processor is further configured to:

allocate a text space to the loadable module from unused space in the instruction RAM；

allocate a data space to the loadable module from unused space in a data RAM； and

relocate addresses associated with each internal function and each internal variable associated with the loadable module according to start addresses associated with the literal space, the text space, and the data space allocated to the loadable module.
The apparatus recited in claim 17, wherein the processor is further configured to:

release the literal space, the text space, and the data space allocated to the loadable module from the memory after executing a function to unload the loadable module.
An apparatus, comprising:

means for reserving literal memory space to a loadable module configured to run in an absolute addressing mode；

means for generating a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols； and

means for allocating literal space to the loadable module from the reserved literal memory space to initialize the loadable module.
The apparatus recited in claim 19, wherein the literal space is reserved in a valid address range accessible to one or more address-restricted instructions while compiling an operating system binary image.
The apparatus recited in claim 19, wherein the partial linking comprises a relocatable output configured to link symbols external to the loadable module as absolute memory addresses.
The apparatus recited in claim 19, wherein the partial linking comprises an Executable and Linkable Format (ELF) object file.
The apparatus recited in claim 19, further comprising:

means for allocating a text space to the loadable module from unused space in an instruction random access memory (RAM) ；

means for allocating a data space to the loadable module from unused space in a data RAM； and

means for relocating addresses associated with each internal function and each internal variable associated with the loadable module according to start addresses associated with the literal space, the text space, and the data space allocated to the loadable module.
The apparatus recited in claim 23, further comprising:

means for releasing the literal space, the text space, and the data space allocated to the loadable module in response to executing a function to unload the loadable module.
A computer-readable medium storing computer-executable instructions, the stored computer-executable instructions configured to cause one or more processors to:

reserve literal memory space to a loadable module configured to run in an absolute addressing mode；

generate a partial linking that combines one or more object files associated with the loadable module with operating system exported symbols； and

allocate literal space to the loadable module from the reserved literal memory space to initialize the loadable module.
The computer-readable medium recited in claim 25, wherein the literal space is reserved in a valid address range accessible to one or more address-restricted instructions while compiling an operating system binary image.
The computer-readable medium recited in claim 25, wherein the partial linking comprises a relocatable output configured to link symbols external to the loadable module as absolute memory addresses.
The computer-readable medium recited in claim 25, wherein the partial linking comprises an Executable and Linkable Format (ELF) object file.
The computer-readable medium recited in claim 25, the stored computer-executable instructions further configured to cause the one or more processors to:

allocate a text space to the loadable module from unused space in an instruction random access memory (RAM) ；

allocate a data space to the loadable module from unused space in a data RAM； and

relocate addresses associated with each internal function and each internal variable associated with the loadable module according to start addresses associated with the literal space, the text space, and the data space allocated to the loadable module.
The computer-readable medium recited in claim 29, the stored computer-executable instructions further configured to cause the one or more processors to:

release the literal space, the text space, and the data space allocated to the loadable module in response to executing a function to unload the loadable module.