This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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: Relocating code on cortex m3 but keeping data constant


Dan Baldor <danbaldor@gmail.com> writes:

> I am trying to relocate the text segment but keep the .data at the
> same place.

Are you trying to relocate the text segment to an address known at link
time, or are you trying to relocate it to an address which is not known
until runtime?

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

I don't know.  I wouldn't be surprised either way.  I would be very
surprised if there were a way to do this which was not documented in the
gcc manual.

Ian


> 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


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