This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Reg initializing data in segments other than .data
- From: Nick Clifton <nickc at redhat dot com>
- To: Prasad Venkata Boddupalli <bprasad at CS dot Arizona dot EDU>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 09 Jan 2006 16:52:04 +0000
- Subject: Re: Reg initializing data in segments other than .data
- References: <20051227030809.GC2770@bubble.grove.modra.org> <Pine.LNX.4.64.0601051517400.15253@lectura.cs.arizona.edu>
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