[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A. Platform-Specific Information for the Run-Time Libraries

The GNAT run-time implementation may vary with respect to both the underlying threads library and the exception handling scheme. For threads support, one or more of the following are supplied:

For exception handling, either or both of two models are supplied:

This appendix summarizes which combinations of threads and exception support are supplied on various GNAT platforms. It then shows how to select a particular library either permanently or temporarily, explains the properties of (and tradeoffs among) the various threads libraries, and provides some additional information about several specific platforms.

A.1 Summary of Run-Time Configurations  
A.2 Specifying a Run-Time Library  
A.3 Choosing the Scheduling Policy  
A.4 Solaris-Specific Considerations  
A.5 IRIX-Specific Considerations  
A.6 Linux-Specific Considerations  
A.7 AIX-Specific Considerations  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.1 Summary of Run-Time Configurations











alpha-openvms
rts-native (default)
Tasking native VMS threads
Exceptions ZCX
pa-hpux
rts-native (default)
Tasking native HP threads library
Exceptions ZCX
rts-sjlj
Tasking native HP threads library
Exceptions SJLJ
sparc-solaris
rts-native (default)
Tasking native Solaris threads library
Exceptions ZCX
rts-m64
Tasking native Solaris threads library
Exceptions ZCX
Constraints Use only when compiling in 64-bit mode;
Use only on Solaris 8 or later.
See section A.4.2 Building and Debugging 64-bit Applications, for details.
rts-pthread
Tasking pthreads library
Exceptions ZCX
rts-sjlj
Tasking native Solaris threads library
Exceptions SJLJ
x86-linux
rts-native (default)
Tasking pthread library
Exceptions ZCX
rts-sjlj
Tasking pthread library
Exceptions SJLJ
x86-windows
rts-native (default)
Tasking native Win32 threads
Exceptions SJLJ


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.2 Specifying a Run-Time Library

The `adainclude' subdirectory containing the sources of the GNAT run-time library, and the `adalib' subdirectory containing the `ALI' files and the static and/or shared GNAT library, are located in the gcc target-dependent area:

 
target=$prefix/lib/gcc-lib/gcc-dumpmachine/gcc-dumpversion/

As indicated above, on some platforms several run-time libraries are supplied. These libraries are installed in the target dependent area and contain a complete source and binary subdirectory. The detailed description below explains the differences between the different libraries in terms of their thread support.

The default run-time library (when GNAT is installed) is rts-native. This default run time is selected by the means of soft links. For example on x86-linux:

 
 $(target-dir)
     |
     +--- adainclude----------+
     |                        |
     +--- adalib-----------+  |
     |                     |  |
     +--- rts-native       |  |
     |    |                |  |
     |    +--- adainclude <---+
     |    |                |
     |    +--- adalib <----+
     |
     +--- rts-sjlj
          |
          +--- adainclude
          |
          +--- adalib

If the rts-sjlj library is to be selected on a permanent basis, these soft links can be modified with the following commands:

 
$ cd $target
$ rm -f adainclude adalib
$ ln -s rts-sjlj/adainclude adainclude
$ ln -s rts-sjlj/adalib adalib

Alternatively, you can specify `rts-sjlj/adainclude' in the file `$target/ada_source_path' and `rts-sjlj/adalib' in `$target/ada_object_path'.

Selecting another run-time library temporarily can be achieved by the regular mechanism for GNAT object or source path selection:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.3 Choosing the Scheduling Policy

When using a POSIX threads implementation, you have a choice of several scheduling policies: SCHED_FIFO, SCHED_RR and SCHED_OTHER. Typically, the default is SCHED_OTHER, while using SCHED_FIFO or SCHED_RR requires special (e.g., root) privileges.

By default, GNAT uses the SCHED_OTHER policy. To specify SCHED_FIFO, you can use one of the following:

To specify SCHED_RR, you should use pragma Time_Slice with a value greater than 0.0, or else use the corresponding `-T' binder option.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.4 Solaris-Specific Considerations

This section addresses some topics related to the various threads libraries on Sparc Solaris and then provides some information on building and debugging 64-bit applications.

A.4.1 Solaris Threads Issues  
A.4.2 Building and Debugging 64-bit Applications  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.4.1 Solaris Threads Issues

GNAT under Solaris comes with an alternate tasking run-time library based on POSIX threads -- rts-pthread. This run-time library has the advantage of being mostly shared across all POSIX-compliant thread implementations, and it also provides under Solaris 8 the PTHREAD_PRIO_INHERIT and PTHREAD_PRIO_PROTECT semantics that can be selected using the predefined pragma Locking_Policy with respectively Inheritance_Locking and Ceiling_Locking as the policy.

As explained above, the native run-time library is based on the Solaris thread library (libthread) and is the default library.

When the Solaris threads library is used (this is the default), programs compiled with GNAT can automatically take advantage of and can thus execute on multiple processors. The user can alternatively specify a processor on which the program should run to emulate a single-processor system. The multiprocessor / uniprocessor choice is made by setting the environment variable GNAT_PROCESSOR to one of the following:

-2
Use the default configuration (run the program on all available processors) - this is the same as having GNAT_PROCESSOR unset

-1
Let the run-time implementation choose one processor and run the program on that processor

0 .. Last_Proc
Run the program on the specified processor. Last_Proc is equal to _SC_NPROCESSORS_CONF - 1 (where _SC_NPROCESSORS_CONF is a system variable).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.4.2 Building and Debugging 64-bit Applications

In a 64-bit application, all the sources involved must be compiled with the `-m64' command-line option, and a specific GNAT library (compiled with this option) is required. The easiest way to build a 64bit application is to add `-m64 --RTS=m64' to the gnatmake flags.

To debug these applications, a special version of gdb called gdb64 needs to be used.

To summarize, building and debugging a "Hello World" program in 64-bit mode amounts to:

 
     $ gnatmake -m64 -g --RTS=m64 hello.adb
     $ gdb64 hello

In addition, the following capabilities are not supported when using the `-m64' option:

-fstack-check does not work together with -m64.
Any application combining these options crashes at startup time.

Call-chain backtrace computation does not work with -m64.
Thus the gnatbind switch -E is not supported.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.5 IRIX-Specific Considerations

On SGI IRIX, the thread library depends on which compiler is used. The o32 ABI compiler comes with a run-time library based on the user-level athread library. Thus kernel-level capabilities such as nonblocking system calls or time slicing can only be achieved reliably by specifying different sprocs via the pragma Task_Info and the System.Task_Info package. See the GNAT Reference Manual for further information.

The n32 ABI compiler comes with a run-time library based on the kernel POSIX threads and thus does not have the limitations mentioned above.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.6 Linux-Specific Considerations

The default thread library under GNU/Linux has the following disadvantages compared to other native thread libraries:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.7 AIX-Specific Considerations

On AIX, the resolver library initializes some internal structure on the first call to get*by* functions, which are used to implement GNAT.Sockets.Get_Host_By_Name and GNAT.Sockets.Get_Host_By_Addrss. If such initialization occurs within an Ada task, and the stack size for the task is the default size, a stack overflow may occur.

To avoid this overflow, the user should either ensure that the first call to GNAT.Sockets.Get_Host_By_Name or GNAT.Sockets.Get_Host_By_Addrss occurs in the environment task, or use pragma Storage_Size to specify a sufficiently large size for the stack of the task that contains this call.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Mail Server on June, 15 2005 using texi2html