HP UX Software Transition Kit (STK) manual Improving Shared Library Performance with -B symbolic

Improving Shared Library Performance with -B symbolic

The linker supports the -B symbolic option which optimizes call paths between procedures when building shared libraries. It does this by building direct internal call paths inside a shared library. In linker terms, import and export stubs are bypassed for calls within the library.

The benefit of using -B symbolic option is that it helps improve application performance and the resulting shared library is slightly smaller. The -B symbolic option is useful for applications that make a lot of calls between procedures inside a shared library, and when these same procedures are called by programs outside of the shared library.

NOTE: The -B symbolic option applies only to function references in a shared library.

Example Using -B symbolic

For example, to optimize the call path between procedures when building a shared library called lib1.s, use -B symbolic as follows:

$ ld -B symbolic -b func1.o func2.o -o lib1.s

NOTE: The +e option overrides the -B symbolic option. For example, when you use +e symbol, only symbol is exported and all other symbols are hidden. Similarly, if you use +ee symbol, only symbol is exported, but other symbols exported by default remain visible.

Since all internal calls inside the shared library are resolved inside the shared library, user-supplied modules with the same name are not seen by routines inside the library. For example, you cannot replace internal libc.sl malloc() calls with your own version of malloc() if libc.sl was linked with -B symbolic.

Comparing -B symbolic with -h and +e

Similar to the -h(hide symbol) and +e (export symbol) linker options, -B symbolic optimizes call paths in a shared library. However, unlike -hand +e, all functions in a shared library linked with -B symbolic are also visible outside of the shared library.

Case 1: Building a Shared Library with -B symbolic

Suppose you have two functions to place in a shared library. The convert_rtn() calls gal_to_liter().

1.Build the shared library with -b. Optimize the call path inside the shared library with -B symbolic.

$ ld -B symbolic -b convert.o volume.o -o libunits.sl

2.Two main programs link to the shared library. The main1 calls convert_rtn() and main2 calls gal_to_liter().

$ cc -Aa main1.c libunits.sl -o main1

$ cc -Aa main2.c libunits.sl -o main2

Figure 4 (page 35) shows that a direct call path is established between convert_rtn() and gal_to_liter() inside the shared library. Both symbols are visible to outside callers.

34 Determining How to Link Programs or Libraries (Linker Tasks)