This is a general question about relocation of data and bss section.
When code is linked with linker script allocating all sections including
.bss and .data located in flash area
and all the sections are copied by itself into RAM, how are the data and bss
section relocated?
In the case of text, I know, PIC can run text in different memory area from
that assigned by linker.
However, what happens to .bss and .data ?
For example, gloable variable "a" is defined and assigned its address
0xFFF00200 (flash area) by linker
and map file tells its address 0xFFF00200.
When the area in which global variable "a" is located is copied into RAM and
the location of "a" is changed to 0x00000200 (RAM area),
does the code using "a" such as "a = a+1;"operate normally?
If the address of "a" is still 0xFFF00200 after code is copied, "a = a+1"
will not operate normally becausea is located in flash and will not be
updated.
How can the address of "a" be changed to 0x00000200 ?
Kim
"Kim, Jeong-Hwan" wrote:
>
> This is a general question about relocation of data and bss section.
>
> When code is linked with linker script allocating all sections including
> .bss and .data located in flash area
> and all the sections are copied by itself into RAM, how are the data and bss
> section relocated?
> In the case of text, I know, PIC can run text in different memory area from
> that assigned by linker.
> However, what happens to .bss and .data ?
> For example, gloable variable "a" is defined and assigned its address
> 0xFFF00200 (flash area) by linker
> and map file tells its address 0xFFF00200.
> When the area in which global variable "a" is located is copied into RAM and
> the location of "a" is changed to 0x00000200 (RAM area),
> does the code using "a" such as "a = a+1;"operate normally?
> If the address of "a" is still 0xFFF00200 after code is copied, "a = a+1"
> will not operate normally becausea is located in flash and will not be
> updated.
> How can the address of "a" be changed to 0x00000200 ?
>
> Kim
Only initialized data needs to be copied (.data).
I believe that references to .data and .bss variables are
made relative to some register (base address). Change the
contents of the register, and you've relocated your data.
--
CU
Andrew S. andrewsa@com.mmot.com {anti-spam: invert '.m'}
Andrew S wrote:
>
> "Kim, Jeong-Hwan" wrote:
> >
> > This is a general question about relocation of data and bss section.
>
> Only initialized data needs to be copied (.data).
>
> I believe that references to .data and .bss variables are
> made relative to some register (base address). Change the
> contents of the register, and you've relocated your data.
This depends on your compiler and linker, but with Metaware you have
the options of SMALL Data and BSS segments which use R2 and R13.
By default these are not used. You need to specially select that
your data segments are linked as sbss and sdata and SDA_BASE
and SDA2_BASE to make this work.
Read your linker manual. It should tell you how to do all this.
The crudest way to do this is to link your data "in the right place"
and then run an AWK script over your HEX file and change all the
lines with the address in the data area to "just after the
code segment" and then copy the data back where it belongs when
your code starts.
Tom Evans
InitialSurnameAt
tennyson.com.au
Andrew S <andrewsa@com.mmot.com> writes:
>"Kim, Jeong-Hwan" wrote:
>>
>> This is a general question about relocation of data and bss section.
>>
>> When code is linked with linker script allocating all sections including
>> .bss and .data located in flash area
>> and all the sections are copied by itself into RAM, how are the data and bss
>> section relocated?
>> In the case of text, I know, PIC can run text in different memory area from
>> that assigned by linker.
>> However, what happens to .bss and .data ?
>> For example, gloable variable "a" is defined and assigned its address
>> 0xFFF00200 (flash area) by linker
>> and map file tells its address 0xFFF00200.
>> When the area in which global variable "a" is located is copied into RAM and
>> the location of "a" is changed to 0x00000200 (RAM area),
>> does the code using "a" such as "a = a+1;"operate normally?
>> If the address of "a" is still 0xFFF00200 after code is copied, "a = a+1"
>> will not operate normally becausea is located in flash and will not be
>> updated.
>> How can the address of "a" be changed to 0x00000200 ?
>>
>> Kim
>Only initialized data needs to be copied (.data).
>I believe that references to .data and .bss variables are
>made relative to some register (base address). Change the
>contents of the register, and you've relocated your data.
>--
>CU
>Andrew S. andrewsa@com.mmot.com {anti-spam: invert '.m'}
As Andrew pointed out, .bss is simply zeroed so, as long as your system
zeros RAM on startup, you are OK there.
The PPC has a concept of register relative addressing with the .sdata
and .sdata2 sections, but most programs spill out of those areas and you
will still have a relocation problem. Also, some compilers don't take
advantage of those conventions.
What is typically done is to link .data at the desired (RAM) address
and then use the object tools (if you are using gnu tools, objcopy,
etc.) to move the .data section to ROM (flash). In your startup
code, _way early_ and before using any initialized .data values
(perhaps in crt0.s), copy your flash .data image into RAM. This requires
you to know where the .data section starts and how long it is. I'll let
you work out these details (check out the labels etext and edata --
I believe they are useful).
Disclaimer: if you are not using the gnu toolset, everything is likely
to be different but similar. With the gnu toolset, I've inserted just
enough errors to make sure you understand the concepts rather than using
the instructions as boilerplate :-).
gvb
--
+---------------------------------------------------------------------------+
| Jerry Van Baren / vanbaren_gerald@si.com / Grand Rapids Mi / 616-241-7973 |
| My employer is a company. Companies are artifacts of a legal system. |
|________________Artifacts are incapable of having opinions.________________|
> When code is linked with linker script allocating all sections
> including .bss and .data located in flash area and all the sections
> are copied by itself into RAM, how are the data and bss section
> relocated?
Other contributors have addressed the case in which code must work in
either place, using PIC and small data segment registers.
If your .data and .bss are not used until after they are copied to
RAM, then you instruct the loader to resolve all references to them
using their RAM addresses. The GNU loader I use lets me specify this
in the command file. For example, to place the .data section in ROM
but resolve references as though it begins in RAM at address 0x1000, I
use:
.data BLOCK(0x1000) : AT 0x1000 {
*(.data)
}
-=- Andrew Klossner (andrew@cesa.opbu.xerox.com)
"Kim, Jeong-Hwan" <frog@lgic.co.kr> wrote in message
news:UYuy6.305$2b5.9359@news2.bora.net...
> This is a general question about relocation of data and bss section.
>
> When code is linked with linker script allocating all sections including
> .bss and .data located in flash area
> and all the sections are copied by itself into RAM, how are the data and bss
> section relocated?
There's a simple trick to this. If you look at the linker control file
syntax you'll find a way of specifying sections that are to be placed at one
address even though they are to be linked at another. In GNU's ld program
its something like.....
.data SECTION (link address): AT (where you want to put it address)
Since the linker also knows how to work variables and has built-in functions
such as ADDR and SIZEOF its possible to place the sections without having to
compute absolute addresses.
The following is a typical GNU control file for a simple ROM montior that's
starts in ROM but then copies itself to RAM after doing the basic
initializing of the processor. (You may recognize the file names as those
from the 8260 sample startup files.) The bulk of the image starts at offset
0x3000 into the ROM, the RAM image starts at 0x700000 and copied with the
image are data sections. The bss, being unitialized, is not loaded. The
startup code will do a long word copy from end_entry to stext for (edata -
stext) / 4 long words. It will then zero out the bss section by zeroing
everything from edata to ebss. (Those labels can be seen by the code -- you
just reference them like any other external symbol.)
Its worth trying to look this stuff up in the manual.
SECTIONS
{
s1 0xFF800000 :
{
config.o(.text)
}
s2 0xFF800100 :
{
vect_tbl.o(.text)
}
s3 0xFF803000 :
{
