Segment 0x1 availability for shared library text
A huge executable consists of more than a single consecutive read-only segment and cannot reside, even partially, in segment 0x1. Since a huge executable cannot itself make use of segment 0x1, this portion of the process address space can be made available for other purposes.
HUGE_EXEC={<segno>|0},shtext_in_one
Since the shared library area's pre-relocated data is useful only when the shared text segment resides in segment 0xD, processes that request this option do not have the benefit of pre-relocated library data. Consequently, any shared library data resides in the process heap. This has the benefit of freeing up all of segments 0x3–0xF for divided use by the process heap (mmap/shmat), and the executable.
maxdata>0xA0000000/dsa
or maxdata=0/dsa
),
allows the process to take advantage of the performance benefits that shared
library text provides.If the process's shared library area is a named area created with the doubletext32 attribute, then there is no pre-relocated data segment and both shared library text segments must be used. In this case, the primary segment (normally located in segment 0xD) is moved to segment 0x1 and the secondary shared library text segment remains in segment 0xF. This maximizes the number of consecutive segments (0x3–0xE) that can be divided for use by the process heap (mmap/shmat), and the executable.
While non-huge executables with maxdata values greater than 0xA0000000 and DSA enabled are prevented from using shared library areas in all cases, a huge executable that (1) uses a named shared library area created with the doubletext32 attribute; and (2) specifies the shtext_in_one attribute, can request a maxdata value of up to 0xC0000000 before forfeiting accessibility to the area.