TNS/R Native Application Migration Guide

Introduction to Native Mode
TNS/R Native Application Migration Guide—523745-001
1-13
Native Object File Format
Native Object File Format
Native object files use a different file format from that of TNS or accelerated object
files. Native object files are in Executable and Linking Format (ELF), a standard format
used for UNIX object files, with HP extensions. The native object file format is the
same in the Guardian and OSS environments and on the PC as part of ETK or TDS.
Native object files are type 700 files in the Guardian environment.
Native object files are either relinkable or executable, but not both. (This is unlike TNS
and accelerated object files, which can be both relinkable and executable.) As the
name implies, a relinkable object file can be linked to produce an executable object file
but it cannot be run. Likewise, an executable object file can be run but it cannot be
linked to produce another executable object file.
The native compilers produce only relinkable object files. The nld utility can produce
either relinkable or executable object files. Relinkable object files can be used as nld
input again. Executable object files can be used as nld input for modifying executable
object file attributes only. Both relinkable and executable object files can be used as
noft input.
For details on the structure of native object files, see the nld and noft Manual.
Signals Facility
Certain critical error conditions occurring during process execution prevent normal
process execution. Most of these error conditions are unrecoverable. In TNS
processes, these errors cause the process to receive a trap. In TNS/R native
processes, these errors cause the process to receive a signal. Native processes do not
receive traps.
Signals are software interrupts that provide a way of handling asynchronous events,
such as timer expiration, detection of a hardware fault, abnormal termination of a
process, or any trap condition normally detectable by a TNS process. Each TNS trap
has a corresponding signal, although the trap number and the signal number are
different.
The Debug and Inspect debuggers display a debugging prompt when a TNS process
receives a trap. The debuggers display a prompt when a native process receives a
signal only if the process had previously entered Debug or Inspect (for example, with a
TACL RUND command). Otherwise, a termination message with the signal name and
number is displayed. Debug and Inspect can be used to display and set signal
information when debugging. for details, see the Debug Manual or the Inspect Manual.
For information on signal behavior, see:
•
ARMTRAP on page 9-2
•
Guardian Programmer’s Guide