* Relocating code on cortex m3 but keeping data constant
@ 2011-02-25 1:56 Dan Baldor
2011-02-27 19:27 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Dan Baldor @ 2011-02-25 1:56 UTC (permalink / raw)
To: gcc-help
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.
Any help you can provide would be greatly appreciated.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Relocating code on cortex m3 but keeping data constant
2011-02-25 1:56 Relocating code on cortex m3 but keeping data constant Dan Baldor
@ 2011-02-27 19:27 ` Ian Lance Taylor
[not found] ` <4D6AFAF4.3000009@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2011-02-27 19:27 UTC (permalink / raw)
To: Dan Baldor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Relocating code on cortex m3 but keeping data constant
[not found] ` <mcrlj10glkg.fsf@google.com>
@ 2011-03-01 1:18 ` Dan Baldor
2011-03-01 3:57 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Dan Baldor @ 2011-03-01 1:18 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Relocating code on cortex m3 but keeping data constant
2011-03-01 1:18 ` Dan Baldor
@ 2011-03-01 3:57 ` Ian Lance Taylor
2011-03-02 0:25 ` Dan Baldor
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2011-03-01 3:57 UTC (permalink / raw)
To: Dan Baldor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Relocating code on cortex m3 but keeping data constant
2011-03-01 3:57 ` Ian Lance Taylor
@ 2011-03-02 0:25 ` Dan Baldor
2011-03-02 0:28 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Dan Baldor @ 2011-03-02 0:25 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
I am trying to relocate the text segment to address known only during
runtime. It looks like this works if I use -msingle-pic-base -fpic to
compile and -pie -fpic and -Bsymbolic during link. I have placed a small
loader at the beginning of code which is compiled without -fpic and it
does the relocations necessary and also initializes R9 to point the
global offset table. The -Bsymbolic seems to give the loader the right
memory addresses for all the segments specified in the linker script.
Only down side is that as I mentioned .rodata will eat up a lot of
memory quickly but looking through the compile options I don't see
anything to change this. One last question: When building gcc to support
this relocation is it sufficient to just set the evironment variable
CFLAGS_FOR_TARGET = -fpic -msingle-pic-base or is there other
environment flags I need to set as well?
Thanks,
Dan
On 28/02/2011 10:57 PM, Ian Lance Taylor wrote:
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Relocating code on cortex m3 but keeping data constant
2011-03-02 0:25 ` Dan Baldor
@ 2011-03-02 0:28 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2011-03-02 0:28 UTC (permalink / raw)
To: Dan Baldor; +Cc: gcc-help
Dan Baldor <danbaldor@gmail.com> writes:
> When building gcc to
> support this relocation is it sufficient to just set the evironment
> variable CFLAGS_FOR_TARGET = -fpic -msingle-pic-base or is there other
> environment flags I need to set as well?
That should be sufficient, I think.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-02 0:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-25 1:56 Relocating code on cortex m3 but keeping data constant Dan Baldor
2011-02-27 19:27 ` Ian Lance Taylor
[not found] ` <4D6AFAF4.3000009@gmail.com>
[not found] ` <mcrlj10glkg.fsf@google.com>
2011-03-01 1:18 ` Dan Baldor
2011-03-01 3:57 ` Ian Lance Taylor
2011-03-02 0:25 ` Dan Baldor
2011-03-02 0:28 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).