V850, linker script problem

[Torsten Mohr]

Hi,

> > 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.

In the Makefile that i use in this small example i also generate
a linker map file and a complete listing.
From the linker map file i can also see the load address (LMA) and the
address (VMA).  Also, objdump -h shows the same results.

> 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.

In other projects i basically did it exactly like this, but this time i
based everything on the existing v850 default linker script.
But maybe the other approach is better, i'll remove any section that is
not needed and then order them as you suggested.  But please note
that the sections .sdata and .tdata that ld complained about are
empty.

> 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. :-)

This brings up another question, to my understanding i need to place
.sdata and .rosdata near together, else i can't chose a __gp that is
within +- 0x8000 of all addresses of those two sections.
What is the preferred way to do that?  At the moment i have placed
.rosdata _into_ .sdata, i did not find a location in ROM that is
near enough to .sdata .  But this can't be the preferred way,
as .rosdata should be in ROM to my understanding.

> > 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.

Ok, i'll do that.  At the moment it seems to be not necessary
because everything links fine without .dynamic, but if at any
time ld complains about it, where would i find information on
where to place it?

> > 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

Just yesterday i took a look into these, i copied crt0.S
into the project directory, changed _start to _mystart
and put _mystart into the reset vector, so my changed
startup code gets executed.  It sets up __ep, __gp and
the stack.  At the moment there's another problem with
this, i'll try to track that down next.  But setting
up "insight" as a simulator for v850 did not work...

> 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.

Yes, the constructors are in ___main, which i don't call
from my startup code at the moment.

> 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. ;-)

I can reproduce it, as mentioned in my previous mail.  In more
detail, this crashes:

  .ctors	:
  {
    ___ctors = .;
    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*crtend(.ctors))
    ___ctors_end = .;
  } >rom

  .tdata ALIGN(4) :
  {
	*(.tbyte)
	*(.tcommon_byte)
	*(.tdata)
	*(.tbss)
	*(.tcommon)
  } > ram AT > rom
  __ep = ADDR(.tdata);

And this is ok, it links fine:

  .tdata ALIGN(4) :
  {
	*(.tbyte)
	*(.tcommon_byte)
	*(.tdata)
	*(.tbss)
	*(.tcommon)
  } > ram AT > rom
  __ep = ADDR(.tdata);

  .ctors	:
  {
    ___ctors = .;
    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*crtend(.ctors))
    ___ctors_end = .;
  } >rom

Regarding objdump -h: i took these informations from the
linker map file, it shows basically the same info (it shows
if there is a different load address).

Also, i tried readelf -S on the single object files to track the
problem with .sdata and .tdata down.  They are not contained in
any of the object files.


Thanks for your hints,
Torsten.