AIX Version 4.3 Differences Guide

• The shared memory allocator internally allocates anywhere in the address
space. The reason for this is that other areas of the kernel, for example the
loader, need to insert segments at ESIDs greater than 0x80000000.
Therefore, shm_insert() is allowed to insert anywhere, but the higher-level
user-interfaces perform the validation for the user level.
Shared Memory User and Exported Kernel Programming Interfaces
The shared memory component has numerous system calls surfaced to the user.
All of these system calls are registered in the 64-bit libc.a and the 64-bit kernel
extension. The following is the list of the 32-bit shared memory system calls:
void* shmat(int shmid, const void *address, int shmflag)
int shmctl(int shmid, int command, struct shmid_ds *buffer)
int shmdt(const void *address)
int shmget(key_t key, size_t size, int shmflag)
int disclaim(char *address, uint len, uint flag)
The following are the new, 64-bit-ready interfaces for the shared memory
services. These interfaces are called directly from the 64-bit kernel extensions
only:
ptr64
int
int
_shmat64(int shmid, ptr64 address, int shmflag)
_shmdt64(ptr64 address)
_disclaim64(ptr64 addr,unsigned len,unsigned flag)
The _shmat64(), _shmdt64(), and _disclaim64() calls do not require parameter
remapping, since they are 64-bit-enabled. They do, however, require 64-bit libc.a
to split their address parameters into two adjacent general purpose registers for
processing in 32-bit mode. the shmctl() call does require parameter remapping on
the pointer to the shmid_ds. Additionally, shmget() takes a size_t as input. This
typedef is an unsigned long, which has different widths in 32-bit and 64-bit
programs.
The prototype to shmget() will not change for 64 bits. The low 32 bits of the 64-bit
size will be passed to the kernel, with the size being range-checked for 32 bits in
the library-side. There will be no increase in size of the supported memory region.
The key_t parameter to shmget() is currently a long. It will be changed to always
be an int. This will be true for 32-bit and 64-bit code to make it invariant. This
allows predictable message-passing between 32-bit and 64-bit processes.
3.2.6.4 User Data and Stack Management
The 32-bit programming interfaces for adjusting a program's data size are brk()
and sbrk():
int brk(void *enddatasegment)
void * sbrk(int increment)
There is a change to the sbrk() interface required by 64-bit mode and UNIX98
standards. For UNIX98, sbrk() needs to take a long on input.
This poses a breakage for those who want to have the UNIX95-behavior of sbrk()
that obeys the preceding prototype, taking an int in 64-bit mode. The problem is
that the 64-bit library wrapper for sbrk() has no way of determining whether it was
passed a 32-bit value or a 64-bit value. The compiler will not ensure that the high
32-bits of a register are 0 for int's. Since most programmers going to 64-bit with
their applications will require some porting effort to do so, changing sbrk() to the
64-Bit Enablement 55