Linux Programming Hints
Before each compile remove the old .o files to ensure that the object code is rebuilt. Executing a make clean may be sufficient; however, be careful-many makefiles will remove more than the .o files and you may need to reconfigure the source code. Often an rm *.o will work more dependably.
If everything has been set up properly, it should now be possible to begin the first compile by entering:
This step compiles the library using the assembler prefixed by the -B switch. This will extract the necessary symbols from the library source into a file called jump.log. From jump.log, the global variables and functions will be extracted into the necessary configuration files where the DLL tools will find them. Once all the source has been compiled, change to the directory that was specified in JUMP_DIR. Jump.log should be in this directory. Now execute the following:
getvars getfuncs rm -f jump.log
These commands will create the files jump.vars and jump.funcs. jump.vars contains a list of the global variables found during the compile, while jump.funcs contains a list of functions. If, for some reason, you don't want to export a symbol found in jump.funcs or jump.vars, move the entry to a file called jump.ignore in the JUMP_DIR directory. Be sure to remove any entries added to jump.ignore from the original file. Now return to the compile directory.
Now you should create the jump.imports file. Since a target was previously defined in Shared.inc, simply enter:
There now should be a file called jump.imports in the JUMP_DIR directory. Nothing needs to be done with this file; it will be used to determine which global variables should be located in one of the imported libraries.
The second compile is necessary to determine the sizes of the global variables. The sizes of the globals must be known so that the GOT pointers can be set properly. Remove the .o files from the previous compile and then do the following:
Now change to the JUMP_DIR directory and execute:
getsize > jump.vars-new mv jump.vars jump.vars-old mv jump.vars-new jump.vars
Before actually building the shared image and stub libraries, the jump table and GOT must be allocated enough storage for all the existing functions and global variables as well as for functions or globals that may be added in revisions to the library. To determine the required number of bytes for the jump table and the GOT, execute the following:
wc -l $JUMP_DIR/jump.funcs wc -l $JUMP_DIR/jump.vars
Multiply the resultant line counts by 8 to calculate a lower bound for the number of bytes required for existing functions and global variables, respectively. These values should be padded significantly to allow for future library expansion. Now edit Shared.inc and replace the settings of SL_JUMP_TABLE_SIZE and SL_GOT_SIZE with the values just determined. If you receive an overflow message while building the image, increase these values. Keep in mind that these sizes should be multiples of 8, and that the values calculated are minimums, and will probably not be sufficient to build the library image.
Now everything should be ready to actually build the shared image and stub. Without removing the .o files, execute:
This will first build the image, and then the stub library. Then the stub and image will be verified to check that the libraries were built properly. If all goes well, the last message should be something like:
Used address range 0x6a37f020-0x6a395020 be aware! must be unique! The stub library and the sharable libraries have identical symbols.
The address range indicated in the first line is somewhat misleading, since a load address of 0x6a380000, not 0x6a37f020, was specified. This is normal. However, make note of the last address since it indicates the last address used by the library. This address is usually padded somewhat to make sure that room is left for expansion. The address range might be recorded as 0x6a380000-0x6a395fff or 0x6a380000-0x6a39ffff, depending on how much space might be required in the future.
The second line indicates that the image and stub libraries were built correctly. If the verification process should indicate that the stub and image differ, an error has occurred. Possibly one of the most common errors is when the JUMP_LIB environment variable and SL_NAME don't match. Double check that these two variables match if there should be a problem. If everything has gone correctly there should now be a stub and image library. The image should be copied to the directory specified by SL_PATH and the stub should be placed where it can be found by the compiler and linker. Once these files have been copied to their final directories, enter:
There should be output similar to the following, indicating that ldconfig has created a symbolic link for the new library in which the name only contains the major version number. This is done because a look-up on the library is done using only the major version number.
libxyz.so.1 => libxyz.so.1.0.0 (changed)
If ldconfig doesn't find the library, make sure that the directory in which the library is located is included in the list in /etc/ld.so.conf. It should now be possible to make use of the new library. Shared.inc, jump.vars, jump.funcs, jump.import and jump.ignore should be saved. These files will be useful if you need to rebuild the library or create a compatible replacement.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Readers' Choice Awards 2013
- Android Browser Security--What You Haven't Been Told
- The Many Paths to a Solution
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- Synopsys' Coverity
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide