This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: Section X overlaps section Y problem.


Jim Blandy <jimb@redhat.com> writes:

> Sergei Organov <osv@topconrd.ru> writes:
> > Jim Blandy <jimb@redhat.com> writes:
> > > Sergei Organov <osv@topconrd.ru> writes:
> > > > On embedded target, to copy at startup some data and/or code from ROM to
> > > > RAM at startup, I've been using the following technique that worked for
> > > > me for years. The last version of binutils where I know it works is
> > > > version 2.10.
> > > 
> > > So, your startup code copies the ROM contents (as given in .vect) into
> > > RAM (covered by .vect_image).  Why do both of those sections have the
> > > same LMA?
> > 
> > No, the opposite. Please take a look at the linker command file snippet
> > once again (I've changed VECT memory region to be called RAM to avoid
> > confusion): 
> > 
> >   [...]
> >   .vect : AT(__vect_image) {
> >     *(.vect)
> >     . = ALIGN(16);
> >   } > RAM
> >   [...]
> >   .vect_image : {
> >     __vect_image = .;
> >     . += SIZEOF(.vect);
> >   } > ROM
> >   [...]
> > 
> > .vect is in RAM but it's LMA is set to be equal to match the address of
> > the fake section .vect_image that is entirely in ROM. The purpose of
> > .vect_image is to provide the LMA value for .vect's AT() and to move
> > current allocation address in the ROM forward by the size of the .vect
> > section. At startup the SIZOF(.vect) bytes of data is copied from
> > __vect_image address (=LMA of .vect) to the VMA of .vect.
> 
> Okay, I see now what you are doing.  Looking at the manual, I see that
> one can also specify an LMA memory region, with AT>.  Perhaps you
> could write your script like this:
> 
>    .vect : {
>      *(.vect)
>      . = ALIGN(16);
>      __vect_image = LOADADDR(.vect);
>    } > VECT AT> ROM
> 
> and omit .vect_image altogether.  But I haven't tried this.

Thank you for the hint. That does the trick though it's slightly less
convenient because of the starting address of the image in ROM is now
defined by the relative position of the above directive w.r.t. other ROM
allocation directives in the linker command file. Provided that
selecting of sections to be put into RAM by file/section name templates
is also position dependent, these two issues may interfere in
undesirable ways. Anyway, this is an interesting solution that is
appropriate in most cases.

In fact I've just found another workaround, -- explicitly marking
.vect_image as NOLOAD:

   .vect_image (NOLOAD): {
     __vect_image = .;
     . += SIZEOF(.vect);
   } > ROM

that for my particular case is even better as it's less changes.

Thank you once again for your help!

-- 
Sergei.


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