I recently fielded a question from a VOS customer who wanted to know how to get his shared virtual memory regions to align between his legacy non-POSIX programs and his new, POSIX-based programs.
This customer had used the create_data_object command to create several different shared virtual memory regions. He had then used a bind control file to ensure that each program referenced the regions in the same order and at the same virtual address. The problem was that no matter how he used the gcc command to bind his new, POSIX-based programs, he couldn’t get the SVM regions to align. The new programs put the SVM regions at different addresses. Even using a bindfile with gcc didn’t help.
The bind map (or the output of the display_program_module command) reveals that POSIX programs always begin with the “s_start_c_program” and “crti” object modules. The s_start_c_program object module appears later in the legacy program, and the crti object module doesn’t appear at all. The presence of these two object modules pushes all subsequent object modules down in the file, which results in the misalignment.
There is no way to prevent gcc from putting these two object modules first in the program module. So, the solution is to change the way the legacy programs are bound. Since SVM regions must start on a page boundary, and since the combined size of the s_start_c_program and crti code regions are less than a page, all we need to do is to allocate an extra, unused page at the start of the legacy programs. Use the create_data_object command to create a 4096-byte data object and put it into the bind control file as the first object module.
We agreed to keep the size of these two programs to 1 page (4096) bytes or less, so this solution will work going forward.
If you have any questions about this technique, please post them below.
Company