3 New Features of This Release
4 Known Problems and Workarounds
- 1 -
1. Introduction
These release notes describe the Base Compiler Development
portion (compiler_dev) of the 6.0 IRIS Development Option
from Silicon Graphics, Inc. They include discussion of
compiler tools, header files, libraries, dynamic shared
objects, and KPIC directives. The 6.0 IRIS Development
Option supports both 64-bit and 32-bit compilation modes.
Note: Packaged with the IRIS Development Option software is
a separate sheet that contains the Software License
Agreement. This software is provided to you solely
under the terms and conditions of the Software
License Agreement. Please take a few moments to
review the Agreement.
This document contains the following chapters:
1. Introduction
2. Installation Information
3. New Features of This Release
4. Known Problems and Workarounds
1.1 Release_Identification_Information
Following is the release identification information for the
Base Compiler Development portion (compiler_dev) of the 6.0
IRIS Development Option:
Software Product Compiler_dev
Version 6.0
Product Code SC4-IDO-6.0
System Software Requirements IRIX 6.0 or later
1.2 Online_Release_Notes
After you install the online documentation for a product
(the relnotes subsystem), you can view the release notes on
your screen.
If you have a graphics system, select ``Release Notes'' from
the Tools submenu of the Toolchest. This displays the
grelnotes(1) graphical browser for the online release notes.
- 2 -
Refer to the grelnotes(1) man page for information on
options to this command.
If you have a nongraphics system, you can use the relnotes
command. Refer to the relnotes(1) man page for accessing
the online release notes.
1.3 Product_Support
Silicon Graphics, Inc., provides a comprehensive product
support maintenance program for its products.
If you are in the U.S. or Canada and would like support for
your Silicon Graphics-supported products, contact the
Technical Assistance Center at 1-800-800-4SGI. If you are
outside these areas, contact the Silicon Graphics subsidiary
or authorized distributor in your country.
- 1 -
2. Installation_Information
The IRIS Software Installation Guide fully documents the
process for installing the Base Compiler Development
software. In addition, each compiler has its own set of
release notes that describes product-specific installation
information.
2.1 3.18_Base_Compiler_Development_Subsystems
The 6.0 Base Compiler Development software (compiler_dev)
includes these subsystems:
compiler_dev.books Base compiler books
compiler_dev.books.dbx Base compiler dbx User's Guide
compiler_dev.hdr Base compiler headers
compiler_dev.hdr.internal Base compiler internal headers
compiler_dev.hdr.lib Base compiler environment headers
compiler_dev.man.base Base compiler components man
pages
compiler_dev.man.ld Base compiler loader man pages
compiler_dev.man.perf Base compiler performance man
pages
compiler_dev.man.util Base compiler utility man pages
compiler_dev.sw Base compiler software
compiler_dev.sw.abi Base compiler ABI software
compiler_dev.sw.base Base compiler components
compiler_dev.sw.ld Base compiler loader
compiler_dev.sw.perf Base compiler performance tools
compiler_dev.sw.util Base compiler utilities
compiler_dev.man.dbx dbx manual page
compiler_dev.man.lib Development environment manual
pages
- 2 -
compiler_dev.man.relnotes These release notes
compiler_dev.sw.dbx dbx debugger
compiler_dev.sw.lib Development libraries
2.1.1 Subsystem_Disk_Space_Requirements This section lists
the compiler_dev subsystems (and their sizes).
If you are installing this software for the first time, the
subsystems listd above (except compiler_dev.hsr.internal)
are selected for installation automatically. They will be
installed when you give the go command unless you request
explicitly that they not be installed (with the keep
command).
- 1 -
3. New_Features_of_This_Release
The features in this chapter are new or significantly
changed in the Base Compiler Development software since the
IRIX 4.0.5 Maintenance release. Section 3.1.1, "MIPSpro
Compilers", deals specifically with those features that are
new to the 6.0 compiler release. Otherwise, except as
noted, changes apply to all versions.
3.1 Compiler_System
This section lists changes and additions to compilers and
development tools since the IRIX 4.0.5 Maintenance release.
3.1.1 MIPSpro_Compilers
o A new suite of compilers is included in this release,
supporting a 64-bit programming model for the R8000
processor. It includes support for the C, C++, and
Fortran programming languages, and is invoked by
specifying the -64 option to the compiler commands.
Effective use of the 64-bit features of the MIPS3 and
MIPS4 architectures involves many changes to the
underlying implementation. Larger (64-bit) integer
registers and more (32 64-bit) floating point registers
yield a modified subprogram call interface. Dealing with
the capabilities of a 64-bit address space yields a 64-
bit ELF object file format which is a natural
transformation plus extensions of the 32-bit ELF format.
Refer to the manuals on porting to 64 bits and assembly
language programming for further information on these
subjects.
o Many of the compiler options, especially for controlling
optimization, are different for the MIPSpro compilers.
For instance, -O3 simply specifies a more aggressive
optimization level instead of the full-program
optimization of the basic MIPS compilers. See the man
pages for more information on options.
o This release of the compilers and operating system uses
dynamic linking as its default linking mode. Dynamic
linking facilitates sharing of library text and platform
independence for developers who which wish to make their
programs take advantage of hardware features when
available without recompilation.
Most features of dynamic linking behave the same way for
32-bit and 64-bit executables. For a more detailed look
at how they differ, see the MIPSpro 64-Bit Porting and
- 2 -
Transition Guide. Detailed information about dynamic
linking can be found in the dso(5) manpage, the ld(1)
manpage and the rld(1) manpage. See also the section
``Dynamic Linking and DSOs" below.
o A CROSS64 Develpment Option is provided with this
release. The CROSS64 Development Environment is intended
for users who want to develop 64-bit applications
targeting an IRIX 6.0 system, but run their development
tools on an IRIX 5.2 system. By installing the CROSS64
Development Option, a user can build 64-bit programs on
an Indy (for example), and later run them on a Power
Challange. It is described in more detail below.
3.1.2 Obsoleting_libmld libmld, either in the form of an
archive or a DSO, will not be released or supported in
future releases. If you use functions in the existing
libmld library, contact the Technical Assistance Center for
details concerning the migration of your libmld function
calls in your existing source code to other calls, probably
in libraries such as libelf, the ELF object-file support
library, and libraries containing symbol table manipulation
routines.
3.1.3 Dynamic_Linking_and_DSOs In earlier versions of IRIX
(pre-5.0), executables were only statically linked. This
means that all references must be resolved (and their
addresses fixed) at link time (by ld(1)). In this release,
such programs, although they might use pre-5.0 shared
libraries (which are referred to now as static shared
libraries) are referred to as non-shared. They are produced
by compiling and linking with the -non_shared option. The
code so created is not position-independent (PIC).
In 5.0 and later IRIX releases, in addition to being
statically linked by ld(1), programs are, by default,
compiled as PIC code and dynamically linked, that is, part
of the program may be relocated dynamically at run time.
There are two types of dynamically linked objects:
o The executable itself. This consists of your main
program and PIC code extracted from all archive
libraries linked with it. Code within the executable
is not relocated at run time, but some of its
references will be. The executable is linked
-call_shared.
o External sharable dynamically linked objects called
dynamic shared objects (DSOs), which are not part of
the executable itself. DSOs and their references may
be dynamically relocated at run time. DSOs are linked
- 3 -
-shared. DSOs by convention have the extension .so. A
DSO may be shared by several users and/or programs,
possibly at different addresses.
You cannot mix non-shared objects and PIC objects in the
same executable.
On this and future release, static shared libraries are
supported only for the use of existing (pre-5.0) executables
that reference them. You can neither create new static
shared libraries nor link new code with existing static
shared libraries.
PIC code satisfies references indirectly by using a Global
Offset Table (GOT), which allows code to be relocated simply
by updating the GOT. Your executable has one GOT, and each
DSO it uses has one GOT.
When a dynamically linked executable is started, the runtime
linker, rld(1), is invoked to prepare the program for
execution. This preparation involves:
o Filling in certain global values.
o Relocating any dynamic shared objects (DSOs) that your
program references.
o Resolving data symbols in DSOs that were unresolved at
static link time by ld(1).
With very few exceptions, all executable objects in this
release are dynamically linked. A new component, the
runtime linker /lib/rld, and all standard DSOs (file
extension .so) are necessary for programs to execute.
More information about these types of objects appears in
Appendix A, ``Frequently Asked Questions about DSOs,'' and
in the IRIX System Programming Guide.
3.1.4 Object_File_Format_Changes The compiler tools and
the link editor now produce ELF format objects and
executables by default. DSO is supported only in ELF
executables and object files. COFF files are run on IRIX
5.0 and later releases with the IRIX 4.0.5 ABI, and ELF
files are run with the IRIX 5.0 and later ABI; hence, the
linker refuses to mix (pre-5.0) COFF and ELF objects.
Two new header files are associated with ELF objects:
/usr/include/elf.h contains definitions that are generic to
all implementations. /usr/include/sys/elf.h contains
definitions specific to the MIPS architecture. See the
- 4 -
System V Application Binary Interface and System V
Application Binary Interface MIPS Processor Supplement,
published by Prentice Hall.
A new object file reader, elfdump(1), is associated with ELF
format files. This program is known on some other SVR4-
compliant systems as dump.
3.1.5 ABI_Development For information about ABI
development issues, see the man pages abicc(1), abild(1),
check_abi_compliance, check_abi_interface and
check_for_syscalls.
3.1.6 Versioning_of_Shared_Objects In the 5.0.1 release, a
mechanism for the versioning of shared objects was
introduced for SGI-specific shared objects and executables.
Note that this mechanism is outside the scope of the ABI,
and, thus, must not be relied on for code that must be ABI-
compliant and run on non-SGI platforms. Currently, all
executables produced on SGI systems are marked SGI_ONLY,
which allows use of the versioning mechanism.
Versioning allows the creator of a shared object to update
it in a way that may be incompatible with executables
previously linked against the shared object. This is
accomplished by renaming the original shared object and
providing it along with the (incompatible) new version.
Versioning is mainly of interest only to developers of
shared objects. It may not be of interest to you if you
simply use shared objects.
3.1.6.1 What_Is_a_Version? A version is part or all of an
identifying version_string that can be associated with a
shared object by using the -set_version version_string
option to ld(1) when the shared object is created.
A version_string consists of one or more versions separated
by colons (:). A single version has the form:
sgi.
where
is a comment string, which is ignored by the
versioning mechanism. It consists of any
sequence of characters followed by a #.
sgi is the literal string sgi.
is the major version number, which is a
string of digits [0-9].
- 5 -
. a literal period.
is the minor version number, which is a
string of digits [0-9].
Here is what to do when building your shared library:
o When you first build your shared library, give it an
initial version, say sgi1.0. Thus, add the option
-set_version sgi1.0 to the command to build your shared
library (cc -shared, ld -shared).
o Whenever you make a compatible change to the shared
object, create another version by changing the minor
version number, for example, sgi1.1, and add it to the
end of the version_string. The command to set the
version of the shared library might now look like
-set_version "sgi1.0:sgi1.1" .
o When you make an incompatible change to the shared
object:
- Change the filename of the old shared object by
adding a dot followed by the major number of one
of the versions to the filename of the shared
object. Do not change the soname of the shared
object or its contents. Simply rename the file.
- Update the major version number and set the
version_string of the shared object when you
create it to this new version, for example,
-set_version sgi2.0.
Here is how this versioning mechanism affects executables:
o When an executable is linked against a shared object,
the last version in the shared object's version_string
is recorded in the executable as part of the liblist.
This can be examined by elfdump -Dl.
o When you run an executable, rld looks for the proper
filename in its usual search routine.
o If a file with the correct name is found, the version
specified in the executable for this shared object is
compared to each of the versions in the version_string
in the shared object. If one of the versions in the
version_string matches the executable's version exactly
(ignoring comments), then that library is used.
- 6 -
o If no proper match is found, a new filename for the
shared object is built by taking the soname specified
in the executable for this shared object and the major
number found in the version specified in the executable
for this shared object, and putting them together as
soname.major. (Remember that you did not change the
soname of the object, only the filename.) The new file
is searched for using rld's usual search procedure.
3.1.6.2 Example: Suppose you have a shared object foo.so
with initial version sgi10.0. Over time, you make two
compatible changes for foo.so, which result in the following
final version_string for foo.so:
initial version #sgi10.0: upgrade I/O#sgi10.1:new devices#sgi10.2
You then link an executable that uses this shared object,
useoldfoo. This executable specifies version sgi10.2 for
soname foo.so. (Remember that the executable inherits the
last version in the version_string of the shared object.)
The time comes to upgrade foo.so in an incompatible way.
Note that the major version of foo.so is 10, so you move the
existing foo.so to the filename foo.so.10 and create a new
foo.so with the version_string:
efficient interfaces #sgi11.0
New executables linked with foo.so use it directly. Older
executables, like useoldfoo, attempt to use foo.so, but find
that its version (sgi11.0) is not the version they need
(sgi10.2). They then attempt to find a foo.so in the
filename foo.so.10 with version sgi10.2.
3.1.7 Runtime_Link_Editor_rld(1) and libdl
o rld is a new program that is invoked when running a
dynamic executable. It maps in shared objects used by
this executable, resolves relocations as ld does at
static link time, and allocates common if required.
rld is mapped in at program startup time by the kernel.
Its path is /lib/rld, but you can change it with the
_RLD_PATH environment variable.
There are two versions: rld and rld.debug. The first
is faster, the second provides debugginh support. Both
are described on the rld(1) man page.
o Options to rld can be specified via the _RLD_ARGS
environment variable. It is possible to replace
libraries without recompiling, get extra information
- 7 -
from the runtime linker, and alter some of the dynamic
linking semantics by specifying arguments in this way.
See the manual page rld(1) for details.
o The functionality previously available in
/usr/lib/libdl.so, a user interface to the dynamic
linker for manipulating the shared objects used by a
dynamic executable, is now part of libc.so.1.
Specifically, this includes the function calls
dlopen(3), dlclose(3), dlsym(3), and dlerror(3).
The following change in rld(1) was made in the 5.0.1 release
of IRIX:
o In release 5.0, rld zeroed the stack space it had used
before invoking the main program. As of release 5.0.1,
it no longer zeroes this space. If your program had a
bug that relied on an uninitialized automatic variable
being zero, the bug may be uncovered by this rld
change. If you suspect this to be the case, the
previous behavior (rld clearing its used stack space at
exit) can be obtained temporarily by adding the option
-clearstack to the environment variable _RLD_ARGS when
you run the program. However, do not rely on this
mechanism; there is no guarantee that the stack space
your program is relying on being zero will not be
dirtied by other startup code in future releases. The
buggy behavior in your program must be corrected. Note
that these problems most often will occur relatively
early in the call graph of your program.
The following change was made to functions in libdl in the
5.0.1 release:
o In the 5.0 release, when a shared object was opened via
dlopen(3x), its symbols became globally visible. This
behavior has been changed to be consistent with SVR4.
As of the 5.0.1 release, objects loaded by one
invocation of dlopen may not directly reference symbols
from objects loaded by a different dlopen invocation.
Those symbols may, however, be referenced indirectly
using dlsym(3x).
See the NOTES section of the dlopen(3x) manual page for
further information.
3.1.8 Changes_to_dbx(1)
o dbx has been reimplemented. The commands and outputs
are virtually the same as previous releases of dbx.
Some non-essential dbx variables have not been
- 8 -
retained.
o This version of dbx may be used on 32- or 64-bit Elf-
format programs and may also be used on COFF format
32-bit programs.
o In expressions, one can use plain / for divide rather
than being required to use // (as was required in the
past). The old form (//) of divide is still supported
though.
o The new program dbxhang(1) has been added to the
release. It enables convenient debugging of programs
that do strange things to the terminal modes of the
window they run in. See the dbxhang man page for
details.
3.1.9 Archiver_ar(1) The default format for the archive
symbol table has been changed. The default is now the same
as ar E and produces an SVR4-compatible symbol table. If
you want to produce the old symbol table format, use ar C.
3.1.10 Sizesize(1) The 6.0 size does not handle COFF
objects. The default output is similar to that of the
previous releases. To get an SVR4 style output, use size
-svr4.
3.1.11 Strip_strip(1) The 6.0 strip does not handle COFF
objects.
3.1.12 Elfdump_elfdump(1) The 6.0 elfdump does not handle
COFF objects. Elfdumps output is similar to that of 5.2
release. To get a more condense output, you can specify
elfdump -no_verbose. To get an SVR4 style output, use
elfdump -svr4. This elfdump is a superset of SVR4 dump.
3.1.13 Nm_nm(1) The 6.0 nm gives different results for
64-bit and 32-bit objects. For 32-bit objects, we use the
same nm as the one in release 3.19. For 64-bit objects, we
use an nm that is a superset of SVR4's nm. The nm that is
used for 64-bit objects doesn't handle COFF objects.
3.1.14 Dis_dis(1) The 6.0 dis does not handle COFF
objects.
3.1.15 Link_Editor_ld(1) The following changes have been
made to the linker ld(1):
o As of release 5.0.1, the linker can adjust executables
to avoid certain problems with early versions of the
R4000. If the -no_jump_at_eop flag is on (it is on by
- 9 -
default), small amounts of padding are added between
component objects to avoid placing a branch instruction
at the end of a page. Slightly smaller executables and
significantly faster executables can result by turning
this option off (using the -allow_jump_at_eop flag).
Binaries built either way should be compatible across
all Silicon Graphics systems, but those made with
-no_jump_at_eop (the default) often show performance
gains on R4000 systems. These flags are irrelevant for
programs compiled with -mips4 because the R8000
processor does not have this hardware bug and no
padding is performed by the linker.
o New options have been added to ld(1) for aligning
variables in the global uninitialized data area (bss).
See the manual page for ld(1) for options with names
beginning with -X. These new options are unique to
IRIX and might change across releases.
o The default object and executable file format has been
changed to ELF. Under no circumstances can you link
together ELF and (old) COFF objects.
o Static shared libraries are replaced by dynamic shared
objects. The linker no longer supports linking with
static shared libraries. However, existing executables
linked with static shared libraries continue to work.
o By default, the linker reports all undefined and
unresolved symbols and exits with non-zero status.
However, for shared linking, it is possible to allow
unresolved symbols at static link time and rely on the
runtime linker to complete the resolution at run time.
If you specify -ignore_unresolved, the linker does not
consider unresolved symbols to be errors. This option
is turned on by the driver if the environment variable
SGI_SVR4 is set.
o The linker now reports a maximum of 50 warnings
messages. If you want all warning messages to be
printed, specify -wall.
o The following new flags are related to DSO support.
Please refer to the manual page for details: -B
symbolic, -non_shared, -call_shared (default), -shared,
-all, -exclude, -no_archive, -transitive_link (default)
-check_registry, -update_registry, -set_version,
-ignore_unresolved (default), -no_unresolved,
-no_library_replacement, -soname, -delay_load, and
-export.
- 10 -
3.1.16 Optimizer_(uopt(5)) New optimizations and
improvements to existing optimizations have been added to
uopt.
o -strictIEEE
The optimizer performs some floating point expression
simplification in the presence of floating point
constants, which can cause different behavior in
programs that rely on strict adherence to the IEEE
floating point standard. An example is the
substitution of zero for multiplication by zero. This
flag suppresses such optimizations.
o -Wo,-nomultibbunroll
The optimizer now unrolls loops whose bodies contain
branches (that is, loop bodies made up of multiple
basic blocks). This internal optimizer flag suppresses
such unrolls.
o -noinline
This option disables the inlining operation performed
by umerge under -O3. This flag is not meaningful if
-O3 is not specified.
o -inline_to
The default value of this parameter is 0. A positive
value of this parameter asks umerge to perform
additional inlining of calls to leaf routines up to the
specified level, in addition to its automatic decision
mechanism. A value of 1 causes all calls to leaf
procedures to be inlined. A value of 2 additionally
causes all calls to procedures that became leaves due
to level 1 inlining to be inlined, etc. Under this
option, a procedure becomes a leaf in the inlined
output code if and only if the procedure's maximum
distance from a leaf in the call graph is less than or
equal to the value of this parameter. This option is
not affected by the -noinline option and is meaningful
only if -O3 is not specified.
o -nokpicopt
This option tells uopt not to perform the special
optimization for accesses of global variables when
compiling shared. (-kpicopt is the default for shared
compilations)
- 11 -
o -kpicopt
This option tells uopt to perform the special
optimization for accesses of global variables that are
not gp-relative whether compiling shared or non-shared.
(-nokpicopt is the default for non-shared compilations;
however, some programs, particularly if compiled -G 0,
might benefit from this optimization even if compiled
-non_shared.)
3.1.17 Assembler_(as(1))
o The 6.0 assembler now supports 64-bit instructions, and
can generate 64-bit ELF object files. The COFF format
is not supported for 64-bit objects. The 64-bit
objects contain DWARF debugging support rather than
MDEBUG.
o The calling conventions and register usage for 64-bit
objects is different from the 32-bit conventions, so
you should become familiar with the new conventions.
The MIPSpro 64-Bit Porting and Transition Guide is
useful for porting code from 32 to 64 bits. Also see
the standard include files and which
are parameterized for 32-bit or 64-bit code.
o Most of the optimizations like software pipelining and
cross-basic-block scheduling have been removed from the
assembler; these optimizations are now done in the
back-end, and thus only happen for high-level code.
The assembler still does instruction scheduling for the
user.
o There are three new assembler directives for the
generation of 64-bit PIC (Position-Independent Code).
These directives are ignored if not doing a 64-bit
shared (PIC) compile.
o .cpsetup reg, reg2/offset, label
By convention, reg == t9, and the label is the
procedure entry. The second argument can be either
another register (for the case of a leaf routine with
no frame) or a stack offset, and is used to store the
value of $gp. This directive expands into:
sd gp, offset(sp)
lui gp, %hi(%gp_rel(label))
daddiu gp, gp, %lo(%gp_rel(label))
daddu gp, gp, reg
- 12 -
o .cpreturn
This directive expands into:
ld gp, offset(sp)
where "offset" is the same value used in the previous
.cpsetup.
o The .cpsetup/.cpreturn sequence replaces the
.cpload/.cprestore sequence that is used in 32-bit PIC
code.
o The other new directive is
.cplocal reg1
It specifies a register (typically not $gp) to be used
as context pointer. It has effect only within a
procedure (i.e., it is turned off automatically at the
end of each procedure).
o An example of an assembly language PIC program that can
be compiled both in both -32 and -64 mode is as
follows:
#include
#include
FRAMESZ = 2*SZREG
RAOFF = FRAMESZ
GPOFF = FRAMESZ-SZREG
.globl foo
.ent foo,0;
foo:
.frame sp,FRAMESZ, ra
.set noreorder
.cpload t9 # 32-bit gp-prolog
.set reorder
INT_SUB sp, FRAMESZ # setup frame
.cpsetup t9, GPOFF, foo # 64-bit gp-prolog
.cprestore GPOFF # 32-bit save gp
INT_S ra, RAOFF(sp) # save return reg
LA t0, x # load addr of x
INT_L a0, (t0) # load content of x
jal bar # call function bar
INT_L ra, RAOFF(sp) # restore return reg
.cpreturn # restore gp
INT_ADD sp, FRAMESZ # remove frame
jr ra # return
- 13 -
.end foo
3.1.18 Libraries The following changes to the libraries
that are part of the compiler system were made in the 5.0.1
release.
o With the 5.0.1 and later releases, C++ code is linked
by default with the new shared object libC.so, which is
a shared version of libC.a. See the C++ release notes
for further information.
3.1.19 Performance_Tools This section includes changes to
pixie(1), pixstats(1), and prof(1). pixstats(1) has been
eliminated from this and future releases. Its functionality
has been integrated into prof(1). This section also
includes a detailed note (with an example) on using these
tools with DSOs.
o The program cord(1) is not provided in this release.
o These tools will not work on executables produced on
IRIX 4 systems. For IRIX 4 functionality, you should
invoke the IRIX 4 pixie,prof, and pixstats explicitly.
They will not be run automatically under the IRIX
compatibility mode.
3.2 The_CROSS64_Development_Environment
Please note that the CROSS64 Development Environment is
designed to produce 64-bit objects only. These objects will
run only on a machine running IRIX 6.0 in 64-bit mode. 32-
bit objects developed with the CROSS64 Development
Environment may not run.
In order to use the CROSS64 tools you need a special
environment, which includes setting the environment
variables:
o SGI_ABI
o PATH
o TOOLROOT
o COMP_TARGET_ROOT
o ROOT
These are described below:
- 14 -
o SGI_ABI
You will need to set an environment variable SGI_ABI to
-64 so that the compiler knows that you want to produce
64-bit objects. Otherwise, the compiler normally
defaults to produce objects compatible with the host
system, which are likely to be 32-bit.
o PATH
In order to pick up the proper commands, you will need to
set your PATH to prefer /usr/cross64/usr/bin over the
usual pathnames. This is so you get the correct cc, f77,
ld, dump, and so forth. For example:
setenv PATH /usr/cross64/usr/bin:$PATH
rehash
o TOOLROOT
The compilation tools are set to pick up the compiler
binaries automatically from the cross development tree if
you set the environment variable TOOLROOT to usr/cross64.
Once this is set the compiler passes (fec, be, asm, ld64,
etc.) are executed from the CROSS64 area.
o COMP_TARGET_ROOT
The driver normally picks up include files and libraries
from /usr/include and /usr/lib (in 64-bit compilations,
libraries normally come from /usr/lib64 and
/usr/lib64/mips4). Setting COMP_TARGET_ROOT to
/usr/cross64 causes the driver to pick up include files
and libraries rooted at /usr/cross64.
o ROOT
If you use make or its derivatives to compile your
programs, you may want to set them up to use ROOT and
TOOLROOT. (You need to set the environment variable ROOT
to /usr/cross64).
Inspect it to make sure that references to absolute
system dorectories are changed. Many of the SGI sample
Makefiles and generated Makefiles are already set up to
use these variables.
3.2.1 Considerations for Developing X Programs in the
CROSS64 Environment To develop X programs, you need to
include the X development tools in your path. For example:
setenv PATH /usr/cross64/usr/bin/X11:/usr/cross64/usr/bin:$PATH
When using the xmkmf command, use the -64 -mips4 flag so it
can generate a Makefile for the 64-bit environment:
- 15 -
cd
xmkmf -64 -mips4
3.2.2 Considerations for Developing Motif Programs in the
CROSS64 Environment To develop Motif programs, you also
need to include the X development tools in your path, as
above.
When using the mmkmf command, use the -64 flag so it can
generate a Makefile for the 64-bit environment:
cd
mmkmf -64
# ignore any error message "getabi: Not found"
3.2.3 Considerations for Developing OpenGL Programs in the
CROSS64 Environment You should be able to compile openGL
programs in the cross development environment. Please note
that if you use commondefs in your Makefile, you may want to
comment out the GLDOPTS variable. The GLDOPTS variable
points to the 32-bit library directory, not the 64-bit
library directory. The compiler (given no flags) will
search the right directories automatically.
In your Makefile, add the line:
GLDOPTS =
3.3 Library_and_System_Call_Functionality
The following additions and changes were made to library and
system call functionality between versions 5.2 and 6.0 of
the IRIS Development Option.
o The MIPSpro C compiler supports long double arithmetic
using the ANSI C standard syntax. Most of the standard
transcendental functions in libm and libc are
supported. See specific man pages for names and
prototypes. Most of the long double routines are named
by prefixing the letter 'q' to the double precision
routine's name; for example, qsin is the long double
version of sin.
The following long double routines are NOT supported in
the first release: acosh, asinh, atanh, cbrt, drand48,
drem, erand48, erf, erfc, expm1 gamma, j0, j1, jn,
lgamma, log1p, y0, y1, yn
- 16 -
See the man page for math(3M) for details regarding
long double arithmetic. Note that long double
operations on this system are only supported in "round
to nearest rounding" mode (the default). The system
must be in "round to nearest rounding" mode when
issuing long double arithmetic operations or calling
any of the long double functions, or incorrect answers
will result.
- 1 -
4. Known_Problems_and_Workarounds
4.1 MIPSpro_Compilers
o The MIPSpro C compiler requires adherence to the ANSI C
requirement (3.3.2.2) which states that calls to varargs
routines must have a prototype visible at the call and
the function definition (if they pass floating point
actual arguments), and must use the stdarg.h (ANSI C
section 4.8) interface. The compiler will issue a
warning if it sees floating point parameters passed to
printf, sprintf, or fprintf without a prototype. ld will
issue a warning if possible when floating point
parameters are passed to varargs routines without
prototypes visible at the call site. However, ld cannot
issue such warnings if the call is via a function pointer
to an anonymous function.
SGI-provided library functions like printf all use
prototype-style declarations in the system header files,
so simply including the relevant header files in files
which call them satisfies this requirement. User-written
code should use the same practice.
o The 64-bit subprogram call interface passes all
parameters in 64-bit containers. The first eight are
passed in registers, sign-extending integers smaller than
64 bits to 64-bits. Beyond the first eight, parameters
smaller than 64-bits (except structs) are passed right
justified in the 64-bit container in memory. Therefore,
passing an int (32-bit) parameter and referencing it in
the callee as a long or pointer (64-bit) may pick up
extraneous garbage in the high-order half of the value.
Use of prototypes will solve this problem by
automatically converting the passed value; otherwise, the
normal C rules for correspondence between actual and
formal parameters must be followed. An important
potential cause of this problem is defining "NULL" as "0"
and then passing it as an unprototyped pointer parameter.
To avoid this, define "NULL" as "0L" or "(void *)0".
o There are a number of similar issues which arise in
porting C code to the 64-bit programming model. See the
MIPSpro 64-bit Porting and Transition Guide for more
information.
o Invalid optimization of volatile variables is possible.
In the example:
volatile int i;
... = i + i;
- 2 -
The optimizer may generate one load and use the value
loaded twice (PV 179224).
o The compiler generates code for struct return values with
sizes 1-32 bits or 65-96 bits which does not conform to
the 64-bit ABI. Instead of left-justifying the last
partial doubleword of the struct in the return register,
it is returned in the low-order half of the register.
The generated code works, but the next release will
require recompiling both caller and callee for such
functions if either is recompiled (PV 230819).
4.2 dbx
o The format of the "active" command output is incorrect.
o The "whereis" command does not work correctly.
o When using the CROSS64 development environment, C++
driver doesnt know how to handle the COMP_TARGET_ROOT
environment variable. A workaround is to specify your
library location explicitely, that is:
CC -show -non_shared hello.C -L/usr/cross64/usr/lib/nonshared
o If _RLD_ROOT is set to pick up a different libc.so.1, and
breakpoints are set in libc.so.1 before running the
program, the breakpoints become permanent, that is they
cannot be deleted. A workaround is to stop in main before
setting any breakpoints in libc.so.1.
o In single-user state, if dbx core dumps on startup, try
the command sequence
/etc/init.d/network start
/etc/init.d/network stop
Then retry dbx. Usually the message before the abort
will start with ERROR: bind failed errno 126.
o If a store instruction updates a location which is being
tracked with a stop/when/trace and the cpu is an R8000
and the store instruction is in any delay slot (jump or
load) and the program is a 32-bit program, the
stop/when/trace may not be triggered and if it is
triggered may print out/use an incorrect value.
o On an R8000: if an interactive function call calls a
function which has anything but a no-op (aka 'nada') in
- 3 -
the delay slot of a return from that function (jr ra) dbx
will print and cannot print the
function's return value. The function has been executed
and any side effects happened. Clear the incomplete
'return' with the clearcalls command or the return
command.
4.3 Performance_Tools
The following known problems exist in pixie(1):
o Trace features are currently not supported. This is
to say that they have not been tested and thus
cannot be guaranteed to work.
o The -pixie_file option that allows the user to name
the output instrumented executable does not
currently work.
o Executables linked for pc sampling (-p) cannot be
instrumented by pixie and successfully run.
o Objects loaded using dlopen() cannot be instrumented
automatically.
o
The following problems exist in prof(1):
prof (-pixie) -testcoverage or -gprof cannot process
basic block counts for shared libraries. If you
need to process basic block counts, compile the code
with -non_shared flag.
o prof cannot process information from dynamic shared
libraries that have been opened with dlopen() and
have the same name, but differenct paths, i.e.:
/path1/libl.so
/path2/libl.so
4.4 Libraries
These are known problems in compiler-associated libraries:
o In general, routines in the -lm43 library might not
conform to either SVR4 or IEEE with respect to
diagnostics or return values. These discrepancies are,
however, described in the manual pages of the
constituent functions. (See Section 3.5 for math
library changes). The following particular problems
are known (these problems exist in -lm43 routines, but
- 4 -
not in -lm routines):
- The -lm43 functions pow, hypot, and cabs might
fail to return NaN when given a NaN argument. The
return value in these cases is Infinity for hypot
and cabs and either Infinity or zero for pow.
- If the magnitude of their argument is greater than
one, the -lm43 functions acos and asin return
zero, pi/2, or pi rather than the (correct) NaN.
- The -lm43 y0, y1, and yn functions return NaN
(instead of -Infinity) when the argument is zero.
These functions also produce underflow
inconsistently (with respect to -lm).
- The version of gamma in the -lm43 library loops
indefinitely if it is given Infinity as an
argument.
o The single-precision version of log, logf, is
imprecise. In particular, logf(x) might not
approximate -logf(1/x) as well as expected. The
double-precision version does not exhibit this
behavior.