z/OS V1R9.0 UNIX System Services Command ... - Christian Grothoff

c89, cc, and c++
hexadecimal format is referred to as the hexadecimal floating-point
format, and is unique to IBM System z9 hardware. This is the
default.
IEEE754
Base 2 IEEE-754 binary format. The IEEE-754 binary format is
referred to as binary floating-point format. The IEEE-754 binary
format is the more common floating point format used on other
platforms.
If you are porting an application from another platform, transmitting
floating-point numbers between other platforms or workstations, or your
application requires the larger exponent range provided by IEEE-754 binary
format, then you should consider using IEEE floating-point. The z/OS XL
C/C++ User’s Guide contains more information on the FLOAT compiler
option.
Example: The following is an example of compiling with IEEE-754 binary
floating point format:
c89 -o outfile -Wc,’float(ieee)’ file.c
-g Specifies that a side file that contains symbolic information is emitted and
the executable is to be loaded into read/write storage, which is required for
source-level debugging with dbx, and other debuggers.
72 z/OS V1R9.0 UNIX System Services Command Reference
For 32-bit compiles, if the _DEBUG_FORMAT=ISD environment variable is
exported, then -g specifies that the output file (executable) is to contain
symbolic information and is to be loaded into read/write storage, which is
required for source-level debugging with dbx, and other debuggers.
When specified for the compilation phase, the compiler produces symbolic
information for source-level debugging.
When specified for the link-editing phase, the executable file is marked as
being serially reusable and will always be loaded into read/write storage.
dbx requires that all the executables comprising the process be loaded into
read/write storage so that it can set break points in these executables.
When dbx is attached to a running process, this cannot be guaranteed
because the process was already running and some executables were
already loaded. There are two techniques that will guarantee that all the
executables comprising the process are loaded into read-write storage:
1. Specify the -g option for the link-editing phase of each executable. After
this is done, the executable is always loaded into read/write storage.
Because the executable is marked as being serially reusable, this
technique works except in cases where the executable must be marked
as being reentrant. For example:
v If the executable is to be used by multiple processes in the same
user space.
v If the executable is a DLL that is used on more than one thread in a
multithreaded program.
In these cases, use the following technique instead:
2. Do not specify the -g option during the link-editing phase so that the
executable will be marked as being reentrant. Before invoking the
program, export the environment variable _BPX_PTRACE_ATTACH with
a value of YES. After you do this, then executables will be loaded into
read/write storage regardless of their reusability attribute.