This is the mail archive of the binutils@sourceware.org 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: V850, linker script problem


On Mon, May 08, 2006 at 10:45:01PM +0200, Torsten Mohr wrote:
> i rearragned the sections in the linker script and by that
> the problem disappeared.
> 
> I know that the order of sections matters, but the problem
> here was not obvious to me and i can't really explain it.

I'm not sure whether you've been using v850e-objdump -h your_elf_file.
Checking the VMA and LMA columns to confirm where the linker's location
counter departs from what you expect usually allows some deduction of
possible causes.

Your mileage may vary, but one way to minimise this problem is to place
all the "> ROM"  output sections first. Now the coast is clear for the
"> RAM" output sections, some of which (e.g. .data) will have a modified
LMA (using either "AT" syntax). With all the plain ".text"-ish stuff
already located, the script won't be asking the location counter to hop
about so much. This also causes .data to follow all .text in ROM, which
is neat.

So long as you set __gp and __ep in roughly suitable places, you can lay
the carpet squares different ways. (It's your memory, and your embedded
system. :-)

> 
> It would be great if anybody could give me a hint on where to
> place the sections in the target, especially .dynamic .

If neither you nor gcc put anything into these input sections, you're
free to zap them from your linker script. Not liking too much clutter in
mine, I've simply deleted a lot of them. If ever you're one short,
there'll soon be an error message naming it specifically, so it's not
even painful to chuck 'em out in bunches.

> Basically, i think i need to clear all RAM sections and
> copy all RAM>ROM sections from ROM to RAM.  Is that correct?

This is normally done by crt<n>. The quickest way to acquire
them for this target is to grab newlib's
newlib-1.13.0/newlib/libc/sys/sysnecv850/crt0.S
newlib-1.13.0/newlib/libc/sys/sysnecv850/crt1.c

The ld info page very briefly describes what's normally done. (search
for crt0). Newlib does the bss init in assembler. crt1.c runs
constructors, and may not be needed.

If you have any form of .noinit section, you won't want to clear all
of RAM. Setting variables in the linker script allows the loops to
clear/copy just what is needed. (This also minimises boot time.)

> Erik, is the test below still needed?

Nope, you've cleared this hurdle. :-)

If the schedule permits though, it would help at this stage of the
learning curve, to use objdump -h etc. to gain more insight into where
and why the location counter took a left turn. (Or you can wait until
next time it happens. ;-)

Good luck.

Erik


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