Improving Program Performance Function Visibility in z/TPF C++ Load Modules October 2, 2015 10/2/20151American Express Public

Improving Program PerformanceFunction Visibility in z/TPF C++ Load Modules

April 19, 2023

04/19/23 1American Express Public

04/19/23 2

Improving Program Performance: Function Visibility

Introduction

The TPF operating system, the platform on which the Credit Authorization System (CAS) resides was updated in March 2010 to the most recent version of the IBM supported operating called z/TPF. This was an AIU required project that will enable future scalability, performance, and enhanced functionality to meet business growth and complexity. To mitigate the risk of migration to the new operating system, the new system was installed without taking advantage of any new capabilities offered by the upgrade, even those capabilities which would provide performance improvements.

The z/TPF Post-Migration project is tasked to evaluate and implement some of the new capabilities of the new operating system and to use them to provide performance, quality, or maintainability improvements to the TPF platform and the mission critical CAS application.

One requirement is to explore and implement C++ Shared Object (CSO) Function visibility to optimize program performance, which will be the focus of this presentation.

American Express Public

04/19/23 3

Improving Program Performance: Glossary

Visibility The scope of a function exposed the application system.

Global Visibility Functions with Global Visibility are callable from any function defined to the system.

Local Visibility Functions with Local Visibility are callable only from within the Load Module or Shared Object in which they are defined.

Static functions Static functions are only callable from within the object in which they are defined.

Load Module A TPF Program Load Unit (see Shared Object)

Object The resulting output file from a C++ compiled source file.

Shared Object Same as a Load Module, the output of 1 or more link edited object files in to a single Load Module. All z/TPF Load Modules are Shared Objects.

Procedure Linkage Table (PLT) Contains the addresses of referenced functions outside of the calling shared object

Global Offset Table (GOT) Holds absolute addresses in private data, enabling sharing of program text across multiple processes

GCC GNU Compiler Collection. The C++ compiler used to create z/TPF C++ Shared Objects.

Glossary


04/19/23 4


What is Visibility?

Visibility describes the scope in which a function is exposed to the application system. A function can be classified (in terms of visibility) as:

Global – Function can be called from any function in any load module.Local – Function can only be called from any function within the load module in which it is defined.Static – Function can only be called from any function within the object in which it is defined.

Descriptions and example call diagrams of each type of function are presented on the following slides.


04/19/23 5


Global Visibility

Functions with Global Visibility may be called from any Load Module in the system. In TPF 4.1 they were called exported functions. Functions with Global Visibility are designed to perform a service that can be shared across many Load Modules.

Software development time is saved as functions can be ‘reused’ as needed and if successfully implemented do not require detailed testing if imported into a load module. The concept of build / test once, re-use many times applies to functions with Global Visibility.

Load Module AObject File A.1

call globalFunction()Object File A.2

call globalFunction()

Load Module BObject File B.1


Load Module CObject File C.1

call globalFunction()Object File C.2


Load Module GObject File G.1

globalFunction()

Example of Global Function Call:Green Arrows represent valid function callsRed Arrows represent invalid function calls


04/19/23 6


Local Visibility

Functions with Local Visibility may be called from any object within the load module in which they are defined. Functions with Local Visibility perform a service that is shared across more than 1 object file of a single Load Module.

The difference is a Local function is not callable outside of the Load Module in which it is defined. Functions with Local Visibility provide a common service that is “local” to the load module in which it is defined..

Example of Local Function Call:Green Arrows represent valid function callsRed Arrows represent invalid function calls

Load Module L

Object File L.1call localFunction()

Object File L.2localFunction()call localFunction()

Object File L.3call localFunction()

Load Module A

Object File A.1call localFunction()


04/19/23 7


Static Visibility

Functions with Static Visibility may be called only from within the object file in which they are defined. Static functions provide the fastest call linkage between functions as they may only be called from within the object file in which they are defined.

For static functions, the compiler will include the absolute address of the start of the function at the program location of a call to a static function. One use of static functions is to provide program structure / modularity to program design and implementation.

Example of Static Function Call:Green Arrows represent valid function callsRed Arrows represent invalid function calls

Load Module S

Object File S.1call staticFunction()

Object File S.2staticFunction()call staticFunction()

Object File S.3call staticFunction()

Load Module A

Object File A.1call staticFunction()


04/19/23 8

Improving Program Performance: Visibility in TPF 4.1

TPF 4.1 Visibility and the OS/390 C/C++ CompilerFunctions defined in Dynamic Link Libraries (DLLs) are made public or “visible” to programs outside of the module in which they are defined by:

Coding the name of the function within the parenthesis of a #pragma export () pre-processor directive.

The OS/390 C++ preprocessor would create an external reference entry to the export file of the load module.

Any load module that needs to call the exported function would need to include a @IMPORT DS entry in its build script file to resolve the external reference, allowing for a complete build of the load module.

In Dynamic Load Modules (DLMs), the only function with Global Visibility is the external entry point function, all others have Local Visibility.


04/19/23 9

Improving Program Performance: Visibility in z/TPF

z/TPF Visibility and the GCC C/C++ CompilerIn z/TPF all Load Modules are Shared Objects, and by default, the GCC constructs ALL functions with Global Visibility. The compiler and linker must be instructed to hide functions that do not require Global Visibility. This is accomplished using 1 of the following methods.

Single Entry Point Shared Object:This is the z/TPF equivalent to a DLM. The program entry point is identified in the load module’s make file using the APP_ENTRY := ENTRYNAME entry. To insure only the entry point is visible, the APP_EXPORT := ENTRY line is coded in the makefile. Including this entry will inform the GCC to build all functions with Local Visibility, except for the specified entry point function. Functions can be specified with Static Visibility using the method described below (provided it meets the requirements for static visibility).

Multiple Entry Point Shared Object Functions with Local Visibility:This is equivalent to a non-static Local function that is NOT called from outside of the shared object in which it is defined. This type of function is only called from within the Load Module that contains the object.

To “hide’ these types of functions from outside of the load module, the code the GCC attribute __attribute__((visibility("hidden"))).

Using this method, the function is visible only from within the load module in which it is defined.

Single or Multiple Entry Point Shared Object Functions with Static Visibility: Functions that are called only from within the object in which they are defined should be declared as static functions. This type of function provides the most efficient type of linkage, thus resulting in the most optimal function call performance.


04/19/23 10

Improving Program Performance: Design Considerations

Program Design Considerations

The decision of what type of visibility that should be applied to a function is dependent upon the use of the function in the application system. The following process flow is provided to assist with program design

Is the function callable from outside this

Load Module?

No Further Action Required function

has Global Visibility

Yes

Is the function callable outside of this object?

Code__attribute__

(visibility((“hidden)) before function

prototype

Yes

Declare and define function as static

functionNo

No


04/19/23 11

Improving Program Performance: Programming Examples

Functions with Global VisibilityAs stated, the GCC and Linker will build all functions with Global Visibility unless instructed to do otherwise. So there is no special attributes or declarations required for a function to have Global Visibility. However, functions should only have Global Visibility when they are callable from outside of the Load Module in which they are defined. This type of function is useful for library functions that serve a role that can be shared by many load modules in the application or enterprise. A WWCAS Example would be the Date Conversion functions made visible from Load Module DZ71

void myGlobalFunction(void);void myGlobalFunction(void){

printf(“My global function/n”);return;

}

void myGlobalFunction(void);void myGlobalFunction(void){

printf(“My global function/n”);return;

}

Function with Global Visibility Program Example


04/19/23 12


Global Visibility: Function Call LinkageLinkage For Global Functions

Pro

cedu

re L

inka

ge T

able

2nd H

alf o

f P

roce

dure

Lin

kage

T

able

Dyn

amic

Lin

ker

Cal

ling

Fun

ctio

n

Function Call to function in

different Shared Object

Load Address of the called Function

GOT Address

Transfer control to code referenced

by Address

Has this Shared Object

Called the function before?

Address in GOT is function address

YES

Load Offset in Symbol Table

associated with called function

Transfer control to Special 1st entry of

the PLT

Locate Real Address of the

symbol

Call Dynamic Linker with Offset

and address of caller

Function Return Called Function

Function Call

Store Address in GOT

Address in GOT is 2nd half of

Procedure Linkage Table

NO

1. The calling function, branches to the Procedure Linkage Table (PLT) entry of the called function. If this is the first call to the called function, the PLT contains the address to a PAT Stub entry of the load module that contains the called function.

The PLT entry code branches to aforementioned address.

2. The PAT Stub Entry points to the PLT of the load module that contains the called function. Using the Symbol Table Offset entry of the called function, a branch to the first entry of the called modules PLT is taken.

3. The first entry of the PLT branches to the dynamic linkage routine which obtains the address of the called function is obtained from the PLT, which is returned to the called module and updated in the calling module’s PLT entry for the called function.

4. A branch to the function address is taken, executing the function.

5. Subsequent calls to the function by this Shared Object branch directly to the called function’s address.

OpportunityFunctions declared as Global functions, when only used as Local functions or static functions result in wasted space for the symbol tables, PLT entries. Execution time for Global Functions is longer due to the need to locate the function addresses in memory. Therefore only functions that require Global scope should be built as Global Functions.

This statement does not in any way discourage the design and use of Global Functions. Appropriate use of Global functions can reduce software development and maintenance costs.


04/19/23 13


Functions with Local VisibilityTo instruct the GCC and Linker to build functions with Local Visibility, use of the GCC visibility (“hidden”) attribute is required to be placed before the function prototype. Use of this attribute instructs the GCC to not build an external symbol table entry for the function making it callable from any function defined in the load module in which the local function is defined. Functions should have Local Visibility when they are callable from outside of the object file in which they are defined, but not outside of the load module in which they are defined. This type of function would provide a common service callable by one or more functions defined in multiple object files.

__attribute__((visibility("hidden")))void myHiddenFunction(void); void myHiddenFunction(void){

printf(“My hidden function/n”)return;

}

__attribute__((visibility("hidden")))void myHiddenFunction(void); void myHiddenFunction(void){

printf(“My hidden function/n”)return;

}

Function with Local Visibility Program Example


04/19/23 14


Local Visibility: Function Call Linkage Linkage For Local Functions

Ca

llin

g F

un

ctio

n Function Return Called Function

Function Call to function in same Shared

Object

Function Call Address Supplied by Linkage Editor

1. The Program Linkage Editor, supplies the address of the called function outside of the calling function’s object.

2. The calling function, branches to the address of the called function.

OpportunityLocal functions provide the performance benefit of avoiding the dynamic linkage to locate the address of the called function built as a Global Function. Locally called Global functions have the address of the function supplied by the Linkage Editor at build time. If a Global Function is only called locally, consider changing the scope of the called function to Local or static, to obtain the performance benefits.


04/19/23 15


Static FunctionsTo instruct the GCC and Linker to build static function, the function prototype and header must include the keyword static before the function return type. Use of the static keyword instructs the GCC to insert the address of the start of the function in the function call branch instruction. Since a static function is only to be called from within the object in which it is defined, it is the most efficient type of function call as the function address is known at compile time and can be included in the branch address of the calling function

static void myStaticFunction(void); static void myHiddenFunction(void){

printf(“My static function/n”)return;

}

static void myStaticFunction(void); static void myHiddenFunction(void){

printf(“My static function/n”)return;

}

Function with Local Visibility Program Example


04/19/23 16


Static Visibility: Function Call LinkageLinkage For Static Functions

Ca

llin

g F

un

ctio

n

Function ReturnFunction Call to function in same Object

Called Function

Function Call

Since the address of a static Function is known at compile time, the address of the function is supplied by the compiler and the function is called directly.

OpportunityIf a Global or Local Function is only called from within the object in which it is defined, consider changing the scope of the called function to static, to obtain the performance benefits.


04/19/23 17

Improving Program Performance: Questions


04/19/23 18

Improving Program Performance: References

References

Useful information provided here for individual research and education.

Visibility Presentation from the Orlando 2008 TUGPresentation by IBM on Program Optimization using Visibilityhttp://www-01.ibm.com/software/htp/tpf/tpfug/tgf08/Visibility.pdfzSeries ELF Application Binary Interface SupplementVery technical document on Extended Linkage Format and function call linkagehttp://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.htmlHow to Write Shared Libraries Ulrich Drepper Red Hat Inc.Another very technical document on library development and Visibilityhttp://people.redhat.com/drepper/dsohowto.pdfDynamic Linking and Loading, www.iecc.comWeb Article on Run Time Linkinghttp://www.iecc.com/linker/linker10.htmlOptimizing Performance using VisibilityWhite Paper upon which this presentation is based.


Documents

Improving Program Performance Function Visibility in z/TPF C++ Load Modules October 2, 2015 10/2/20151American Express Public