z/TPF Program Management - IBM

More documents

Recommendations

Info

14 z/TPF Program Management Individual functions can be made visible by using the visibility attribute; add __attribute__ ((visibility("default")) to the functions you want to make visible. Note: Use this option for shared objects that contain only C language code because runtime problems can occur when you use this option on a shared object that contains C++ code. For more information about potential problems when you use visibility with C++ classes, see “Special considerations for C++ classes” on page 15. v LIST is used to indicate that the list of visible functions is provided in an export file. As with ALL, the -fvisibility=default compiler option (used in conjunction with the -fvisibility inlines=default compiler option for C++ programs) is used at compile time to make the functions visible; however, at link time, the export file provides: – A list of functions that are to be hidden. – A list of functions that are visible. Note: You must use the LIST option and export files when hiding functions that are coded in assembly language, because there is no assembly option that is equivalent to the -fvisibility option. For more information, see “Export files” on page 15. v ENTRY is used to indicate that only the function specified by APP_ENTRY is made visible. This is also controlled at link time by using the base/exp/app_entry.exp export file. For more information, see “Export files” on page 15. Examples v To make all of the functions for a given program visible except for the ftpc_get_file function, specify APP_EXPORT := ALL in the makefile for the program and code the following in your C/C++ application source code: __attribute__ ((visibility("hidden"))) size_t ftpc_get_file (void *ptr, size_t size, size_t nmemb, void *stream) { ... } Adding the attribute hides the C/C++ function. v To hide all of the functions for a given program except for the mq_msg function, specify APP_EXPORT := VISIBILITY in the makefile for the program and code the following in your C/C++ application source code: __attribute__ ((visibility("default"))) char *mq_msg(size_t buffer_length); Adding the attribute makes the C/C++ function visible. v In this example, the makefile for program ABCD makes all functions visible by default. However, the application hides uncallableFunction( ) by declaring it as a static function; the application also hides anotherUncallableFunction( ) by using the visibility("hidden") attribute. An important distinction to make is that the scope of the hidden function in terms of visibility is the shared object, while the scope of the static function is limited to the object. abcd.mak: APP := ABCD APP_EXPORT := ALL C_SRC := program.c program.h:
Stubs void callableFunction( ); void anotherCallableFunction( ); static void uncallableFunction( ); __attribute__ ((visibility("hidden"))) void anotherUncallableFunction( ); Special considerations for C++ classes C++ classes have a number of vague linkage entities; for example, typeinfo and vtable. These entities take on the visibility attribute of the class; therefore, if a class is hidden, the entities are hidden, which might have undesirable side effects. Some side effects include not being able to be inherited from a class in a different shared object and not being able to get thrown by an exception. For example, a common problem that is introduced when you compile a class with the -fvisibility=hidden option is when the now-hidden class needs to run a constructor from another shared object (such as running a constructor for an inherited class); it appears to compile and link, but you will receive a runtime linkage error. Note: Unless you know that the C++ logic is contained in the same shared object without the need to use CPP1 or any other C++ library, avoid using APP_EXPORT := VISIBILITY. In general, it is best not to use the visibility option for C++ object-oriented programs because of the danger of generating runtime errors that are difficult to debug. Instead, take advantage of the inherent characteristics of C++ object-oriented programs, such as encapsulation, namespaces, inheritance, and other characteristics. If, however, you do use the visibility option for C++ programs, use it with declarations; in most cases, you do not need to specify the visibility option in the definition. Export files Also called version scripts, export files in the z/TPF system are meant to be used when you have C/C++ functions that are coded in basic assembly language (BAL) that need to be hidden (not shared globally); the only way to hide them is by using an export file. With an export file, you can hide functions that were visible at assemble (or compile) time. However, at link time, you cannot make visible any functions that were hidden at assemble or compile time. The executable and linking format (ELF)-compatible compilers support export files for z/TPF applications that require specific symbols to be modified. For more information about export files, go to http://www.gnu.org. For more information about using export files with the MakeTPF build solution, see “Create an export file” on page 69 and “Update export files” on page 70. Stubs are used to resolve external references between BSOs. The control files that are shipped by IBM contain an entry to generate a stub file that contains a list of programs with entry points (including transfer vectors). This stub file is entered into the linkage editor and gets compiled and link-edited to generate a shared object that contains the entry points for your BAL application programs. The BEGIN macro z/TPF program types and linkage 15
Page 1: z/Transaction Processing Facility E
Page 4 and 5: | | | | | Common deployment . . . .
Page 6 and 7: vi z/TPF Program Management Linux l
Page 8 and 9: 2 z/TPF Program Management
Page 10 and 11: Makefiles Control files 4 z/TPF Pro
Page 12 and 13: | | | | | | | | loadtpf utility Rel
Page 14 and 15: 8 z/TPF Program Management There ar
Page 18 and 19: Figure 2. BAL repackaging Entry poi
Page 22 and 23: Transfer vectors Program linkage 16
Page 26 and 27: Images Loadsets 20 z/TPF Program Ma
Page 28 and 29: present, the program or programs ar
Page 30 and 31: ELF objects and libraries from the
Page 32 and 33: ELF objects and libraries from the
Page 34 and 35: Data loader Pilot Tape (SDF) ZSLDR
Page 36 and 37: Alternate FCTB loader benefits Use
Page 40 and 41: | | | | | | | | | | | | | | | | | |
Page 44 and 45: | | | | | | | | | | | | | | | | | |
Page 46 and 47: | | | | | | | | | | | | | | | 40 z/
Page 52 and 53: | | | | | | | | | | | | | | | | | |
Page 56 and 57: | | | | | | | | | | | | | | | | | |
Page 64 and 65: zos/ obj/ src/ bin/ lst/ obj/ src/
Page 66 and 67: APPL_ROOT := /home/joe/mywork APPL_
Page 68 and 69: Create a single-segment BSO using a
Page 70 and 71:
Adding the line APP_EXPORT := LIST
Page 72 and 73:
66 z/TPF Program Management v CTBX
Page 74 and 75:
3. Update the user control file and
Page 76 and 77:
Update export files this, when an e
Page 78 and 79:
72 z/TPF Program Management Note: I
Page 80 and 81:
3. The JCL also references the form
Page 82 and 83:
76 z/TPF Program Management
Page 84 and 85:
To logically copy CIMR components f
Page 86 and 87:
Page 88 and 89:
offldr programs, as necessary, to c
Page 90 and 91:
84 z/TPF Program Management User: Z
Page 92 and 93:
Page 94 and 95:
Activate a loadset of E-type progra
Page 96 and 97:
v All loadsets containing a particu
Page 98 and 99:
Terminal Addr Index into Selective
Page 100 and 101:
| | | | | | | | | | | | | | | | | |
Page 102 and 103:
| | | | | | | | | | | | | | | | | |
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
| 104 z/TPF Program Management For
Page 112 and 113:
Page 114 and 115:
108 z/TPF Program Management Table
Page 116 and 117:
110 z/TPF Program Management Table
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
118 z/TPF Program Management user e
Page 126 and 127:
120 z/TPF Program Management -outpu
Page 128 and 129:
0 8 0 v A return code indicating th
Page 130 and 131:
124 z/TPF Program Management The fo
Page 132 and 133:
►► 126 z/TPF Program Management
Page 134 and 135:
@CIMR 128 z/TPF Program Management
Page 136 and 137:
The default location is searched fo
Page 138 and 139:
@CTKX 132 z/TPF Program Management
Page 140 and 141:
@DEFINE 134 z/TPF Program Managemen
Page 142 and 143:
136 z/TPF Program Management Additi
Page 144 and 145:
IMGCLEAR specifies whether image-re
Page 146 and 147:
-d specify this parameter, the sour
Page 148 and 149:
@GFKEYPOINT 142 z/TPF Program Manag
Page 150 and 151:
144 z/TPF Program Management v CTKM
Page 152 and 153:
►► @IPL 146 z/TPF Program Manag
Page 154 and 155:
@KEYPOINT Note: The length of the d
Page 156 and 157:
%cpuid loads the specified keypoint
Page 158 and 159:
152 z/TPF Program Management defaul
Page 160 and 161:
information must begin on a new lin
Page 162 and 163:
Page 164 and 165:
Input files The following examples
Page 166:
show all

z/TPF Program Management - IBM

Create successful ePaper yourself

Delete template?

Save as template?