linker scripting: locating overlays after main code

[Graham Nash]

If you are using gcc, you can force text for functions into given 
sections using something like
   
    int __attribute__((section("ovl1.text"))) ovl1func();

and similarly for data and even types. I don't know if this helps you or 
not.

--g


Ian Montgomerie wrote:

>I have a question about linker scripting which I'd be grateful if anyone can
>help me with.
>
>I'm developing overlay support for an embedded system.  For various reasons,
>what I would like to do is build an object file where the main code is
>linked to run at the beginning of DRAM, and a bunch of overlays immediately
>follow it.  The overlays include code from explicitly specified object
>files.  All other code should appear before them.
>
>Example: I have 500 object files, including ovl1.o and ovl2.o.  I would like
>498 of the files to be linked starting at the beginning of DRAM, then
>immediately following that should be an overlay containing ovl1.o and
>ovl2.o.
>
>I hit a big roadblock.  To put all objects other than ovl1 and ovl2 in a
>certain place, I need to create a section using wildcards.  But the moment I
>put a section with wildcards, it grabs EVERY file and I can't reference any
>other objects later in the linker script.  So for example the following
>doesn't work:
>
>.Core:
>{
>    *(.text)
>    *(.rules)
>    *(.need)
>    _etext = .;
>    __etext = .;
>    *(.dynamic)
>    *(.got)
>    *(.plt)
>    *(.data)
>    CONSTRUCTORS
>    _edata  =  .;
>    __edata  =  .;
>    __bss_start = .;
>    *(.bss)
>    *(COMMON)
>}
>
>OVERLAY : NOCROSSREFS
>{
>    .ovl1
>    {
>        ovl1.*(.text)
>        ovl1.*(.data)
>        ovl1.*(.bss)
>    }
>    .ovl2
>    {
>        ovl2.*(.text)
>        ovl2.*(.data)
>        ovl2.*(.bss)
>    }
>}
>
>Is there any way I can get this sort of thing to work?  So far I am using a
>hack where I just hard-code the address where the overlays should show up.
>However, that is not suitable for a production solution where the size of
>.Core can vary greatly depending on the build configuration, and the
>overlays should exactly follow it to save memory.
>
>
>
>
>  
>