Reg initializing data in segments other than .data

H. J. Lu hjl@lucon.org
Thu Jan 5 23:10:00 GMT 2006


On Thu, Jan 05, 2006 at 03:33:53PM -0700, Prasad Venkata Boddupalli wrote:
> Hello,
> 
> In my linker script, there is a section '.shared_section', in which 
> variables that need to be shared across multiple processors go. That 
> section becomes '.shared_segment' in the elf executable. So, the linker 
> script looks as follows:
> 
> ...
> 
> .shared_segment 0x80800000 : {
>     *(.shared_section)
> }
> 
> Variables defined in '.shared_section' should be able to be initialized. 
> That is '.shared_segment' should have the same semantics as the 'data' 
> segment.
> 
> Is there any way of specifying attributes to that segment in the linker 
> script so that linker actually copies the corresponding values of 
> variables to the elf executable ? It would be preferable not to push the 
> 'shared_section' into 'data' segment.

You may need linker changes to do what you want. In fact, I implemented
a very similar scheme for x86, x86-64 and ia64:

    *  The changes to the psABI are

       1. To the section attribute flags, add SHF_INTC_SHARABLE

          #define SHF_INTC_SHARABLE 0x01000000

          described as follows:

          SHF_INTC_SHARABLE

          The section contains data that will be placed in sharable
memory
          accessible from more than one processor in a non-uniform
memory access
          (NUMA) multiprocessor system. Implementations need not
support
          sharable memory.

           
       2. To the special section indexes, add SHN_INTC_SHARABLE_COMMON

          #define SHN_INTC_SHARABLE_COMMON (SHN_LOOS + 10)

          described as follows:

          SHN_INTC_SHARABLE_COMMON

          Symbols defined relative to this section are common symbols,
such as
          FORTRAN COMMON or unallocated C external variables that are
to be
          placed in sharable memory. Implementations need not support
sharable
          memory.

           
       3. To the discussion of special section index value semantics,
add:

          SHN_INTC_SHARABLE_COMMON

          The symbol labels a common block in sharable memory that has
not yet
          been allocated. The linker editor treats these exactly as it
does
          symbols with section index SHN_COMMON, except that it
allocates the
          symbol at an address in sharable memory. Implementations need
not
          support sharable memory.

           
       4. To Special Sections, add the following:

          .sharable_bss, type SHT_NOBITS, attributes
          SHF_ALLOC+SHF_WRITE+SHF_INTC_SHARABLE

          .sharable_data, type SHT_PROGBITS, attributes
          SHF_ALLOC+SHF_WRITE+SHF_INTC_SHARABLE

          .sharable_bss

          This section holds uninitialized data that contribute to the
program's
          memory image. By definition, the system initializes the data
with
          zeros when the program begins to run. The section resides in
sharable
          memory. Implementations need not support sharable memory.

          .sharable_data

          This section holds initialized data that contribute to the
program's
          memory image. The section resides in sharable memory.
Implementations
          need not support sharable memory.

           
       5. To the Program Header section, add a segment type PH_INTC_SHR

          #define PT_INTC_SHR (PT_LOOS + 0x494e540)

          The array element specifies the location and size of a
sharable memory
          information area. The interpretation of the sharable memory
          information area is implementation-dependent. Implementations
need not
          support sharable memory.
           

    * A new assembly directive:

      .sharable_common SYMBOL , LENGTH, ALIGNMENT

          It will generate a SHN_SHARABLE_COMMON symbol of size LENGTH
aligned at ALIGMENT.

    * Special sections:

       1. .sharable_bss.*. It has the same section type and attribute
as .sharable_bss.
       2. .sharable_data.*. It has the same section type and attribute
as .sharable_data.
       3. .gnu.linkonce.shrb.*. It has the same section type and
attribute as .sharable_bss. If linker sees more than one section with
the same name, only one section will be kept.
       4. .gnu.linkonce.shrd.*. It has the same section type and
attribute as .sharable_data. If linker sees more than one section with
the same name, only one section will be kept.
       5. Assembler will set the proper type and attribute for special
sections listed above, regardless what the assembly directive
specifies. No other sections with the SHF_INTC_SHARABLE attribute are
allowed.
       6. For shared library and executable outputs, linker will group
together .sharable_bss, .sharable_bss.* and  .gnu.linkonce.shrb.*
sections to generate a single sharable_bss section, and group together
.sharable_data, .sharable_data.* and  .gnu.linkonce.shrd.* sections to
generate a single sharable_data section. The final .sharable_bss and
.sharable_data sections should be page-aligned and padded to an
integral number of full pages. Linker will provide 2 sets of hidden
symbols, __sharable_bss_start/__sharable_bss_end,
__sharable_data_start/__sharable_end, to mark the start and the end
addresses of .sharable_bss and .sharable_data sections. The value of
the start symbol is the starting address of the section and the value
of the end symbol is the address immediately following the section.


H.J.



More information about the Binutils mailing list