Re: Relocating code on cortex m3 but keeping data constant

[Dan Baldor <danbaldor@gmail.com>]

I am trying to relocate the text segment but keep the .data at the same 
place.  It looks like -msingle-pic-base helps a lot as it allows me to 
move the GOT around independent of the location of the .text segment.  
Is there any way to force the compiler to allocate the const data so it 
is embedded within the .text segment (and referenced using offsets from 
the PC)?  I ran into problems with the location of .rodata section - it 
appears I need to keep it with .data section in order for the code to 
find the references to it properly but this uses up limited SRAM in my 
micro and also complicates my startup code as I can no longer count on 
using the symbol table to find the necessary global values to load the 
code (this is because the strings I am searching for such as "_data" are 
stored in the .rodata section which has not yet been loaded into sram).
Thanks,
Dan

On 28/02/2011 11:39 AM, Ian Lance Taylor wrote:
> Dan Baldor<danbaldor@gmail.com>  writes:
>
>> I have been trying to see if I can implement a minimized dynamic
>> linker to locate the globals necessary to load the code (using the
>> Dynamic section along with the symbol table) and fix up the
>> relocations that are specified in the rel.dyn section.   I already use
>> a liner script with the AT modifier and have tried to relocate the GOT
>> section the way you mentioned but when I do so all the global
>> variables are calculating the location of the .GOT based on the
>> current PC which causes a problem since the distance between the .text
>> segment and the .data segment has changed based on where I load the
>> code.  Is there no way to use -mpic-register and gcc-help@gcc.gnu.org to
>> specify the location of the GOT?  I am not sure how these compiler
>> options work but looking at the assembly that the code generates when
>> I use them I noticed that the references to the PC seem to be removed.
> Please reply to the mailing list, not just to me.  Thanks.
>
> I'm not clear on whether you need fully relocatable code at runtime, or
> whether you just need the data section to be loaded at a different
> address.  That is, do you know the final address where your program will
> run, or not?
>
> -mpic-register sets the register to use for the GOT, it does not set the
> address for the GOT.
>
> -msingle-pic-base assumes that the GOT register is fixed.  You could use
> that to put the GOT wherever you want, as long as you set the register
> correctly.
>
> However, any use of the GOT, or the -fpic option in general, implies
> some sort of dynamic linker.
>
> Ian
>
>> On 27/02/2011 2:24 PM, Ian Lance Taylor wrote:
>>> Dan Baldor<danbaldor@gmail.com>   writes:
>>>
>>>> I am working on a project using a arm cortex-m3 processor that needs
>>>> relocatable code. The relocation is such that the .text and .data
>>>> sections will have a different offset when loaded than what they were
>>>> compiled with (the .text section can be loaded to different sections
>>>> of internal flash while the .data section will always reside in the
>>>> same location of sram). If I keep the .got with .text section I can
>>>> get the global variables to have the correct addresses but my static
>>>> local variables have the wrong address (they are offset from where
>>>> they should be the amount that the .text segment shifted). I think the
>>>> static locals are referenced from the start of the .GOT section which
>>>> is why I am having problems. I am compiling all my c code with –fpic
>>>> and linking with –fpic and –pie. Is there any way to either force the
>>>> static locals (and maybe global variables) to absolute addresses or to
>>>> relocate the .GOT section dynamically? I tried doing by placing the
>>>> GOT section with the data but when I do so code does not locate the
>>>> GOT section correctly. I thought that perhaps I should be using
>>>> |-msingle-pic-base and -mpic-register=|/reg /but so far all attempts
>>>> to use this did not work at all.
>>> If the runtime address is fixed, this is normally done using a linker
>>> script using the AT() modifier; see
>>> http://sourceware.org/binutils/docs-2.21/ld/Output-Section-LMA.html .
>>>
>>> If the runtime address varies, then I don't know that there is a way to
>>> handle this.  Using -fpic/-pie implies the existence of a dynamic
>>> linker.
>>>
>>> Ian