Re: Relocating code on cortex m3 but keeping data constant

[Dan Baldor <danbaldor at gmail dot com>]

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