This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reg initializing data in segments other than .data


Hi Prasad,

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)
}

This creates a *section* in the output file called ".shared_segment". It does not create a *segment* in the output file.


Variables defined in '.shared_section' should be able to be initialized. That is '.shared_segment' should have the same semantics as the 'data' segment.

Be very careful of your semantics here. Sections are different from segments. Assuming that we are talking about ELF format files then, usually, *sections* exist in object files and have names (and other attributes), whereas *segments* exits in executable files and do not have names. (But they do have other attributes).


It appears that what you want is to have the linker create at least two different segments in the executable that it is creating, one for ordinary data and one for shared data. In both of these segments you want the data values to be initialised at the start of run time. There may be other segments for executable code, non initialised data and so on, but that is not important for the moment. Right ?

The linker script syntax does not (currently) allow you to specify segments or their attributes explicitly. Instead the linker attempts to create the minimum number of segments necessary in order to group the sections from the input files in the way that the linker script dictates. (The linker sometimes fails at this task. See the section describing the "not enough room for program headers" error message in the linker documentation).

So, really, all you want is to make sure that the shared data is not put into the segment that is going to be assigned to ordinary data and that the shared data segment created by the linker has the correct attributes. Getting the correct attributes should be easy. The linker calculates the attributes of the segments it creates based on the attributes of the input sections assigned to those segments. So provided that the symbols in your .shared_section sections have the STT_OBJECT attribute (or at least do not have the STT_COMMON attribute) then the linker should end up assigning them to a segment with the SHF_ALLOC attribute, which will ensure that they are initialised at run-time.

In order to make sure that the shared data is not placed into the same segment as the non-shared data you need to make sure that your linker scripts places these two types of input into different output sections which will end up at least a page apart in memory. So starting with your current fragment

> .shared_segment 0x80800000 : {
>     *(.shared_section)
> }

All you really need to do is to make sure that the non-shared data is placed nowhere near 0x80800000. eg:

  .data 0x00000000 : {
      *(.data)
   }

Cheers
  Nick





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]