MAINSAIL System-Specific User's Guides, Appendix B

previous   next   top   contents   index   framed top   this page unframed


B. Flavor-Dependent Configuration on UNIX

B.1. Standard Configuration Files for Available UNIX Flavors

The standard configuration file name for each flavor of UNIX is formed by appending .cnf to the lowercase platform abbreviation.
Table B–1 lists the name of the standard configuration file for each available flavor of UNIX.

Table B–1. Standard UNIX Configuration File Names
Platform Abbreviation Platform Name Configuration File Name
hppa HP's HP-UX on PA-RISC hppa.cnf
hppa64 HP's HP-UX on PA-RISC (64-bit) hppa64.cnf
linia64 Red Hat Linux on IA-64 linia64.cnf
linpn Red Hat Linux on Pentium linpn.cnf
psolrs Sun Microsystems' Solaris on Purify-Compatible SPARC psolrs.cnf
raix IBM's AIX on RISC System/6000 raix.cnf
solrs Sun Microsystems' Solaris on SPARC solrs.cnf
sun4 Sun Microsystems' SunOS on SPARC sun4.cnf

B.2. CONF's STACKSIZE Parameter on 64-Bit Platforms

The minimum recommended value for the size of a stack on 64-bit platforms (HPPA64, LINIA64) is 64 Kb. This is twice the minimum stack size recommended for most other platforms. MAINSAIL will not come up if CONF's STACKSIZE parameter is set too small.

B.3. Producing a Bootstrap on Each Flavor of UNIX

This section shows a sample session for each available flavor of UNIX in which a bootstrap with default parameters is created. The output from CONF in each example is assumed to be named mainsa.s; the final bootstrap file is named mainsa.

If the default configuration file includes foreign MODULEs, these foreign MODULEs must be included in the foreign MODULE list for every MAINSAIL bootstrap. For example, if the default foreign MODULE list contains:

UNISYS
BSDITF

then to add the foreign MODULEs FOO and BAR to a MAINSAIL bootstrap, both UNISYS and BSDITF must be specified along with FOO and BAR. The = abbreviation allowed in multiline CONF commands (see Chapter 6 of the MAINSAIL Utilities User's Guide) may be used to do this:

CONFforeignmodules<eol>
FOREIGNMODULES is
UNISYS
BSDITF
Should be:
=<eol>
FOO<eol>
BAR<eol>
<eol>

B.3.1. Allocating Memory on the HPPA Using mmap

On the HPPA (but not the HPPA64), the default versions of the system library functions sbrk and malloc cannot allocate more than 1 gigabyte of memory. The limitation arises from the way the operating system lays out virtual memory. The memory immediately accessible to a user program is divided into 4 1-gigabyte quadrants. The first quadrant is used for user code, the second quadrant for user data (the “private data space”), and the third and fourth quadrants for shared and mapped code and data. There are two approaches to getting around this limitation: the superior approach involves the explicit use of the -N linker switch and the chatr shell command, whereas the inferior (but automatic) approach entails calling the UNIX system function mmap. However, whereas the mmap approach works for HP-UX versions 9.05 and later, the chatr facility was not introduced until some time after HP-UX version 11.00, so you may be forced to rely on the mmap approach if you are running an older version of the operating system. Whether you use chatr or not, you may want to reserve space for foreign language memory allocations with the MAXFOREIGNMEMORYSIZE CONF parameter.

B.3.1.1. Using -N and chatr to Allow a MAINSAIL Bootstrap to Allocate More Than 1 Gb of Contiguous Memory
You can allow a MAINSAIL bootstrap to allocate as much contiguous memory as possible on HPPA by taking the following steps:

  1. Specify the -N linker switch when creating the MAINSAIL bootstrap. Linking with the -N switch causes data to be placed in the first quadrant, immediately following unmapped user code, instead of at the start of the second quadrant. If a user program is linked with the -N switch, sbrk and malloc can allocate up to 2 gigabytes of memory, minus the amount of space used by the program's unmapped code and by the system stack.

    Linking with the -N switch has the drawback that it marks the bootstrap as unsharable; this may cause more memory to be consumed when you are running multiple MAINSAIL processes at the same time on the same machine.

  2. After specifying the -N linker switch, on operating system versions that support the chatr command, specify to the HP-UX shell one of the following commands (assuming the name of the bootstrap you have built is myBoot):

    • To allow a program's private data space to extend beyond the second quadrant into the third:

      chatr +q3p enable myBoot

    • To allow a program's private data space to extend into the fourth quadrant:

      chatr +q3p enable +q4p enable myBoot

      Specifying +q4p enable does not also implicitly specify +q3p enable; both switches must be specified.

The memory MAINSAIL allocates if you use the above commands is contiguous, which is generally more desirable than the discontiguous memory allocated when MAINSAIL calls mmap.

B.3.1.2. Memory Allocated Automatically by mmap and MAXFOREIGNMEMORYSIZE
On HP-UX version 9.05 and later, memory in the third and fourth quadrants can be allocated to a user process by calling the system function mmap. However, such memory allocation is not guaranteed to be contiguous, which may cause MAINSAIL to manage memory less efficiently, or even to act as if insufficient memory were available when unused memory remains.

On HPPA operating systems versions that support mmap, MAINSAIL allocates memory by calling sbrk or malloc only as long as the amount of memory remaining in the private data space exceeds a user-specifiable threshold. When the amount of available memory falls below the threshold, MAINSAIL resorts to calling mmap to allocate space in other quadrants. The threshold at which MAINSAIL switches from calling sbrk or malloc to calling mmap is specified by the HPPA-specific CONF parameter MAXFOREIGNMEMORYSIZE. The default value of MAXFOREIGNMEMORYSIZE is 16 Mb.

The idea behind this scheme is that MAINSAIL may be linked with significant amounts of foreign code, which may contain many calls to malloc. If MAINSAIL were to use up all of the memory in the sbrk/malloc quadrants, it would do little good for MAINSAIL to switch at the last moment to mmap, since the very next call to malloc made from foreign code would likely fail and probably cause the program to fail as well. The MAXFOREIGNMEMORYSIZE CONF parameter allows you to specify the amount of memory in the sbrk/malloc quadrants that should be reserved for use by foreign code.

When allocating memory from a quadrant with mmap, MAINSAIL does not use the first page in that quadrant. The reasons for this restriction are based on how the PA-RISC maps virtual addresses onto its “spaces”, and are not described here. Not using the first page in a quadrant places a limit of slightly less than 1 gigabyte on the size of the maximum amount of memory that MAINSAIL can allocate as a contiguous block; e.g., ARRAYs on the HPPA must be smaller than a gigabyte. The CONF parameter MINSIZETOALLOCATE should be less than 1 gigabyte if you do not use the chatr command to make the private data space large enough for all of MAINSAIL's data.

B.3.2. Compiling C Code Linked with a MAINSAIL Bootstrap on the HPPA

In order to avoid warnings when linking an HPPA MAINSAIL bootstrap under version 11 or later of the HP-UX operating system, XIDAK recommends that all C code linked with the bootstrap be compiled with the option +DA1.1. Without this switch, on HP-UX version 11, the C compiler generates PA-RISC 2.0 object modules, which causes the linker to issue the warning “At least one PA 2.0 object file was detected. The linked object may not run on a PA 1.x system”.

The +DA1.1 switch is not necessary when using cc to compile C code under version 10 or earlier of the operating system. However, a similar switch (-Wa,+DA1.1) is necessary when cc is used to assemble assembly language files on HP-UX version 10.01 or later.

Example B–2. Making a Bootstrap for the HPPA Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/hppa.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>

On HPPA versions before 10.01:

cc -o mainsa mainsa.s /usr/mainsail/16.20.1/m.o<eol>

On HPPA versions 10.01 and later:

cc -Wa,+DA1.1 -c -o mainsa.o mainsa.s<eol>
cc -o mainsa mainsa.o /usr/mainsail/16.20.1/m.o<eol>

B.3.3. Compiling C Code Linked with a MAINSAIL Bootstrap on the HPPA64

To avoid errors from the linker due to intermixing 32-bit and 64-bit object modules, all C code linked with MAINSAIL on HPPA64 must be compiled with the cc switch that specifies 64-bit object modules; that switch is +DA2.0W.

Example B–3. Making a Bootstrap for the HPPA64 Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/hppa64.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>
cc -Wa,+DA2.0W -c -o mainsa.o mainsa.s<eol>
cc +DA2.0W -o mainsa mainsa.o /usr/mainsail/16.20.1/m.o<eol>

B.3.4. Making a Bootstrap on the RAIX Platform

There are some considerations in making a bootstrap that are unique to the RAIX platform.

B.3.4.1. Memory Allocation Considerations on RAIX
By default, on AIX, you cannot allocate more than 256 megabytes of memory. With the appropriate linker switches and CONF commands, it is possible on AIX for MAINSAIL to allocate more than 2 gigabytes of memory. However, allocating memory in excess of 2 gigabytes carries risks: if the MAINSAIL process that allocated such memory dies unexpectedly, it can continue to consume system resources even after dying.

B.3.4.1.1. sbrk, malloc, and Shared Memory Routines
On AIX, by default, sbrk (and malloc) can allocate no more than 256 Mb of memory because the AIX loader places the heap and the stack at opposite ends of the same 256 Mb memory segment. Once that memory segment is exhausted, subsequent calls to sbrk fail, regardless of whether or not any other memory segments might otherwise be available.

Versions of the AIX operating system starting with 3.2 allow you to specify at link time a maximum user data area size. If such a maximum is specified, the AIX loader places the heap after the system stack, which lifts the old limitation of 256 Mb on the total amount of memory that sbrk can allocate. A maximum user data area size is specified by means of the ld switch -bD:nnnn, where nnnn is the maximum size in bytes. For example, -bD:0x20000000 would specify a maximum user data area size of 0.5 Gb. The maximum argument you can specify to this switch is 2 gigabytes, so that is the maximum allowable heap size obtainable by sbrk or malloc.

The only way on AIX to allocate space besides sbrk and malloc is to call the shared memory functions, shmget and shmat. These functions allocate space in 256 Mb memory segments outside the user data area specified by the -bD option. After a new segment has been allocated, the entire space within the segment is available to the process, but the individual pages within the segment are created only on demand, when they are actually referenced.

One problem that can occur with shared memory is that a program is responsible for explicitly freeing any shared memory it allocates. The operating system does not automatically free the shared memory segments allocated by a program when the program terminates. MAINSAIL is careful to catch as many signals as it can and clean up after itself, but there are some signals (e.g., SIGKILL) that cannot be caught by a user program. Thus, if a program is killed with such a signal (i.e., kill -9), it does not get a chance to free its shared memory. If this happens too many times, the disk fills up and either the machine must be rebooted or the system administrator must realize what has happened and explicitly free the orphan shared memory segments.

MAINSAIL uses shared memory only once it has allocated as much heap space as it thinks it is entitled to. The amount of heap space MAINSAIL is entitled to is the smaller of the CONF parameter MAXMEMORYSIZE and the maximum heap size minus the amount of space reserved for future memory requests made by foreign code; the amount of space reserved for foreign code is specified by the CONF parameter MAXFOREIGNMEMORYSIZE. Furthermore, MAINSAIL may request memory from the heap even after previously requesting (larger) amounts of memory from shared memory, as long as the subsequent request would not impinge on the heap space reserved for foreign code.

You can prevent MAINSAIL from ever calling the shared memory routines by specifying a user data area (with the -bD switch) larger than the sum of MAINSAIL's MAXMEMORYSIZE and MAXFOREIGNMEMORYSIZE parameters, provided that foreign code linked with MAINSAIL uses no more than MAXFOREIGNMEMORYSIZE bytes of memory. Generally speaking, if you set MAXMEMORYSIZE to be large (close to 256 Mb or larger), and you wish to prevent MAINSAIL from using shared memory, then you should specify a correspondingly large value for the maximum user data area size when you link your MAINSAIL bootstraps. In any event, if MAXMEMORYSIZE is larger than 2 Gb, MAINSAIL will be unable to avoid using shared memory once its process has allocated the 2 Gb obtainable by sbrk or malloc.

B.3.4.1.2. The MAXFOREIGNMEMORYSIZE CONF Parameter
MAINSAIL allocates memory by calling sbrk only as long as the amount of memory remaining in the user data area exceeds a user-specifiable threshold. When the amount of available memory falls below the threshold, MAINSAIL resorts to calling the shared memory routines to allocate space outside the user data area. The threshold at which MAINSAIL switches from calling sbrk to calling the shared memory routines is specified by an AIX-specific CONF parameter, MAXFOREIGNMEMORYSIZE. The default value of MAXFOREIGNMEMORYSIZE is 2 Mb.

The idea behind this scheme is that MAINSAIL may be linked with significant amounts of foreign code, which may contain many calls to malloc. If MAINSAIL were to use up all of the memory in the user data area, it would do little good for MAINSAIL to switch at the last moment to the shared memory routines, since the very next call to malloc made from foreign code would likely fail and probably cause the program to fail as well. The MAXFOREIGNMEMORYSIZE CONF parameter allows the user to specify the amount of memory in the user data area that should be reserved for use by foreign code.

B.3.4.2. Bootstrap-Building Commands on AIX OS Version 4.1 and Subsequent Versions of the Operating System
On the RAIX platform, under AIX 4.1 and subsequent versions of the operating system, you must issue different commands to build a MAINSAIL bootstrap from those used under AIX Version 3. This is because the AIX 4.1 assembler, by default, issues warning messages if any instructions are used that are not common to both the POWER architecture (i.e., the original RISC System/6000 architecture) and the PowerPC architecture. Specifying the option -m pwr to as causes the assembler to suppress the warnings when RISC System/6000 instructions are used. The MAINSAIL bootstrap uses such instructions extensively.

Under AIX Version 3, the recommended command to make a MAINSAIL bootstrap is as follows, given the CONF output file mainsa.s, and assuming that the MAINSAIL system directory is given by the environment variable $MS:

cc -o mainsa mainsa.s $MS/m.o -lbsd

On AIX 4.1 and later, the recommended commands are:

as -m pwr -o mainsa.o mainsa.s
cc -o mainsa mainsa.o $MS/m.o -lbsd

B.3.5. Making a Bootstrap on Other Flavors of UNIX

Example B–4. Making a Bootstrap for the LINIA64 Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/linia64.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>
gcc -o mainsa mainsa.s /usr/mainsail/16.20.1/m.o -lcrypt<eol>

Example B–5. Making a Bootstrap for the LINPN Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/linpn.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>
gcc -o mainsa mainsa.s /usr/mainsail/16.20.1/m.o -lcrypt<eol>

Example B–6. Making a Bootstrap for the PSOLRS Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/psolrs.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>
as -P -o mainsa.o mainsa.s<eol>
/opt/SUNWspro/bin/cc -o mainsa mainsa.o /usr/mainsail/16.20.1/m.o -lsocket -lnsl<eol>

Example B–7. Making a Bootstrap for the SOLRS Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/solrs.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>
as -P -o mainsa.o mainsa.s<eol>
/opt/SUNWspro/bin/cc -o mainsa mainsa.o /usr/mainsail/16.20.1/m.o -lsocket -lnsl<eol>

Example B–8. Making a Bootstrap for the SUN4 Platform
MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

*
conf<eol>
MAINSAIL (R) Bootstrap Configurator
Restoring configuration values from file

    
/usr/mainsail/16.20.1/sun4.cnf
CONF<eol>
Bootstrap written in file mainsa.s
*
<eol>

There are two different as commands, one for UNIX versions before 4.0 and one for 4.0 and after. For versions before 4.0:

as -P -DoldRegNames -o mainsa.o mainsa.s<eol>

For 4.0 and after:

as -P -o mainsa.o mainsa.s<eol>

All versions of UNIX take the same cc command:

cc -o mainsa mainsa.o /usr/mainsail/16.20.1/m.o<eol>


previous   next   top   contents   index   framed top   this page unframed

MAINSAIL System-Specific User's Guides, Appendix B