V850, linker script problem

V850, linker script problem

[Torsten Mohr]

Hi,

thank you all for the hints so far, but until now i still
have the problem with the linker script.

I tried to cut down the project as much as possible to only
reflect the strange behaviour and not much more.

In the linker script v850.x i put .data to ROM to copy it into
RAM at startup.  This results in the mapfile:

From linker Script:
  .data :
  {
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
    CONSTRUCTORS
  } > ram AT > rom


From map file:

.data           0x03ffe000        0x0 load address 0x00000678
 *(.data)
 *(.data.*)
 *(.gnu.linkonce.d*)

I expected the same for .tdata and even more for .sdata as this
one has only one entry, but i get:


From linker script:
  .tdata ALIGN(4) :
  {
	*(.tbyte)
	*(.tcommon_byte)
	*(.tdata)
	*(.tbss)
	*(.tcommon)
  } >ram AT>rom

  __ep = ADDR(.tdata);


  .sdata ALIGN (4) :
  {
	*(.sdata)
  } >ram AT > rom
  __gp = ADDR(.sdata) + 0x8000;


From map file:

.tdata          0x00000678        0x0 load address 0x00000678
 *(.tbyte)
 *(.tcommon_byte)
 *(.tdata)
 *(.tbss)
 *(.tcommon)
                0x00000678                __ep = ADDR (.tdata)

.sdata          0x00000678        0x0 load address 0x00000678
 *(.sdata)
                0x00008678                __gp = (ADDR (.sdata) + 0x8000)

At linking i get:
v850e-unknown-elf-ld -o hw2.elf \
        -Map=hw2.map \
        -Tv850.x \
        -nostdlib \
        main.o vectors.o
v850e-unknown-elf-ld: address 0x678 of hw2.elf \
section .tdata is not within region ram

v850e-unknown-elf-ld: address 0x678 of hw2.elf \
section .sdata is not within region ram


I don't know why the address of .tdata and .sdata is set to its
_load_ address and not to an address in RAM.  For .data it
worked as expected.

Of course i can send the sources, the ELF file and any other
data that are needed to this list.

For reference i attach the linker script and the two short source
files to the end of this mail.


Best regards,
Torsten.

v850.x
OUTPUT_FORMAT("elf32-v850", "elf32-v850", "elf32-v850")
OUTPUT_ARCH(v850)
ENTRY(_start)
SEARCH_DIR(.);
EXTERN(__ctbp __ep __gp);

MEMORY
{
  vect(rx)  : org = 0x00000000, len = 0x640
  rom(rx)   : org = 0x00000640, len = 512k
  ram(rwx)  : org = 0x03ffe000, len = 15k
  stack(rw) : org = 0x03fffc00, len = 1k
}

SECTIONS
{
  .vect :
  {
    *(.vect)
  } >vect

  .zdata :
  {
	*(.zdata)
	*(.zbss)
	*(reszdata)
	*(.zcommon)
  } >ram

  .rozdata ALIGN (4) :
  {
	*(.rozdata)
	*(romzdata)
	*(romzbss)
  } >rom


  .text :
  {
    *(.text)
    *(.text.*)
    *(.gnu.warning)
    *(.gnu.linkonce.t*)
  } > rom
  _etext = .;
  PROVIDE (etext = .);

  .call_table_data ALIGN (4) :
  {
    *(.call_table_data)
  } > rom = 0xff
  __ctbp = ADDR(.call_table_data);

  .call_table_text :
  {
    *(.call_table_text)
  } > rom

  .data :
  {
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
    CONSTRUCTORS
  } > ram AT > rom
  .data1	: { *(.data1) } > rom

  .gcc_except_table : { *(.gcc_except_table) } >rom
  .got		: { *(.got.plt) *(.got) } >rom

  .dynamic	: {
    *(.dynamic)
    . = ALIGN(2);
    PROVIDE(__romdatastart = .); /* IF_ROCOPY */
  } >rom


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

  __ep = ADDR(.tdata);


  .sdata ALIGN (4) :
  {
	*(.sdata)
  } > ram AT > rom
  __gp = ADDR(.sdata) + 0x8000;

  .rosdata ALIGN (4) :
  {
	*(.rosdata)
  } >rom

  .sbss :
  {
	__sbss_start = .;
	*(.sbss)
	*(.scommon)
  } >ram
  _edata  = DEFINED (__sbss_start) ? __sbss_start : . ;
  PROVIDE (edata = _edata);
  .bss       :
  {
	__bss_start = DEFINED (__sbss_start) ? __sbss_start : . ;
	__real_bss_start = . ;
	*(.dynbss)
	*(.bss)
	*(COMMON)
  } >ram
  _end = . ;
  PROVIDE (end = .);

  .comment 0		: { *(.comment) }

  .stack :
  {
	__stack = .;
	*(.stack)
  } >stack
}



vectors.S:
.global _start
.global _main
        
        .section .vect,"ax",@progbits

.offset 0x00
        jr      _start



_start:
        jr      _main



main.c:
int main(int argc, char** argv) {
  volatile int i;
  volatile unsigned char p;


  while(1) {
    p++;
    for(i = 0; i < 1000; i++);
  }

  return 0;
}

Re: V850, linker script problem

[Torsten Mohr]

Hi,

i'm sorry to bother you with this one again, but i'm not sure if
the behaviour below is a bug or if i do something wrong.  As
i haven't received any answers i think that nobody can easily
say where i did something wrong.  But i'm not sure about that.

It would be great if anybody could give me a comment if the
behaviour below looks like i did something wrong or if it
basically should work.

At the moment i have no clue on how to continue.  One more thing,
the toolchain is set up on MSYS/MinGW and i manually changed two
thing:
1. changed gcc/Makefile to NOT use/build collect2.exe
2. gcc/config/v850/lib1funcs.asm, line 1459 i commented out
   the change of the section


Thanks for any hints,
Torsten.


> Hi,
>
> thank you all for the hints so far, but until now i still
> have the problem with the linker script.
>
> I tried to cut down the project as much as possible to only
> reflect the strange behaviour and not much more.
>
> In the linker script v850.x i put .data to ROM to copy it into
> RAM at startup.  This results in the mapfile:
>
> From linker Script:
>   .data :
>   {
>     *(.data)
>     *(.data.*)
>     *(.gnu.linkonce.d*)
>     CONSTRUCTORS
>   } > ram AT > rom
>
>
> From map file:
>
> .data           0x03ffe000        0x0 load address 0x00000678
>  *(.data)
>  *(.data.*)
>  *(.gnu.linkonce.d*)
>
> I expected the same for .tdata and even more for .sdata as this
> one has only one entry, but i get:
>
>
> From linker script:
>   .tdata ALIGN(4) :
>   {
> 	*(.tbyte)
> 	*(.tcommon_byte)
> 	*(.tdata)
> 	*(.tbss)
> 	*(.tcommon)
>   } >ram AT>rom
>
>   __ep = ADDR(.tdata);
>
>
>   .sdata ALIGN (4) :
>   {
> 	*(.sdata)
>   } >ram AT > rom
>   __gp = ADDR(.sdata) + 0x8000;
>
>
> From map file:
>
> .tdata          0x00000678        0x0 load address 0x00000678
>  *(.tbyte)
>  *(.tcommon_byte)
>  *(.tdata)
>  *(.tbss)
>  *(.tcommon)
>                 0x00000678                __ep = ADDR (.tdata)
>
> .sdata          0x00000678        0x0 load address 0x00000678
>  *(.sdata)
>                 0x00008678                __gp = (ADDR (.sdata) + 0x8000)
>
> At linking i get:
> v850e-unknown-elf-ld -o hw2.elf \
>         -Map=hw2.map \
>         -Tv850.x \
>         -nostdlib \
>         main.o vectors.o
> v850e-unknown-elf-ld: address 0x678 of hw2.elf \
> section .tdata is not within region ram
>
> v850e-unknown-elf-ld: address 0x678 of hw2.elf \
> section .sdata is not within region ram
>
>
> I don't know why the address of .tdata and .sdata is set to its
> _load_ address and not to an address in RAM.  For .data it
> worked as expected.
>
> Of course i can send the sources, the ELF file and any other
> data that are needed to this list.
>
> For reference i attach the linker script and the two short source
> files to the end of this mail.
>
>
> Best regards,
> Torsten.
>
> v850.x
> OUTPUT_FORMAT("elf32-v850", "elf32-v850", "elf32-v850")
> OUTPUT_ARCH(v850)
> ENTRY(_start)
> SEARCH_DIR(.);
> EXTERN(__ctbp __ep __gp);
>
> MEMORY
> {
>   vect(rx)  : org = 0x00000000, len = 0x640
>   rom(rx)   : org = 0x00000640, len = 512k
>   ram(rwx)  : org = 0x03ffe000, len = 15k
>   stack(rw) : org = 0x03fffc00, len = 1k
> }
>
> SECTIONS
> {
>   .vect :
>   {
>     *(.vect)
>   } >vect
>
>   .zdata :
>   {
> 	*(.zdata)
> 	*(.zbss)
> 	*(reszdata)
> 	*(.zcommon)
>   } >ram
>
>   .rozdata ALIGN (4) :
>   {
> 	*(.rozdata)
> 	*(romzdata)
> 	*(romzbss)
>   } >rom
>
>
>   .text :
>   {
>     *(.text)
>     *(.text.*)
>     *(.gnu.warning)
>     *(.gnu.linkonce.t*)
>   } > rom
>   _etext = .;
>   PROVIDE (etext = .);
>
>   .call_table_data ALIGN (4) :
>   {
>     *(.call_table_data)
>   } > rom = 0xff
>   __ctbp = ADDR(.call_table_data);
>
>   .call_table_text :
>   {
>     *(.call_table_text)
>   } > rom
>
>   .data :
>   {
>     *(.data)
>     *(.data.*)
>     *(.gnu.linkonce.d*)
>     CONSTRUCTORS
>   } > ram AT > rom
>   .data1	: { *(.data1) } > rom
>
>   .gcc_except_table : { *(.gcc_except_table) } >rom
>   .got		: { *(.got.plt) *(.got) } >rom
>
>   .dynamic	: {
>     *(.dynamic)
>     . = ALIGN(2);
>     PROVIDE(__romdatastart = .); /* IF_ROCOPY */
>   } >rom
>
>
>   .tdata ALIGN(4) :
>   {
> 	*(.tbyte)
> 	*(.tcommon_byte)
> 	*(.tdata)
> 	*(.tbss)
> 	*(.tcommon)
>   } > ram AT > rom
>
>   __ep = ADDR(.tdata);
>
>
>   .sdata ALIGN (4) :
>   {
> 	*(.sdata)
>   } > ram AT > rom
>   __gp = ADDR(.sdata) + 0x8000;
>
>   .rosdata ALIGN (4) :
>   {
> 	*(.rosdata)
>   } >rom
>
>   .sbss :
>   {
> 	__sbss_start = .;
> 	*(.sbss)
> 	*(.scommon)
>   } >ram
>   _edata  = DEFINED (__sbss_start) ? __sbss_start : . ;
>   PROVIDE (edata = _edata);
>   .bss       :
>   {
> 	__bss_start = DEFINED (__sbss_start) ? __sbss_start : . ;
> 	__real_bss_start = . ;
> 	*(.dynbss)
> 	*(.bss)
> 	*(COMMON)
>   } >ram
>   _end = . ;
>   PROVIDE (end = .);
>
>   .comment 0		: { *(.comment) }
>
>   .stack :
>   {
> 	__stack = .;
> 	*(.stack)
>   } >stack
> }
>
>
>
> vectors.S:
> .global _start
> .global _main
>
>         .section .vect,"ax",@progbits
>
> .offset 0x00
>         jr      _start
>
>
>
> _start:
>         jr      _main
>
>
>
> main.c:
> int main(int argc, char** argv) {
>   volatile int i;
>   volatile unsigned char p;
>
>
>   while(1) {
>     p++;
>     for(i = 0; i < 1000; i++);
>   }
>
>   return 0;
> }

Re: V850, linker script problem

[Torsten Mohr]

Hi,

i did some more tests:

A:
at the moment i use binutils-2.16.1.  I also tried 2.16 and 2.15.
They show the same behaviour, 2.15 even aborts with
"Speicherzugriffsfehler" (bus error?).


B:
I added another section for testing:

  .myqwe :
  {
    *(.myqwe)
  } > ram AT > rom

in vectors.S:
        .section .myqwe,"w"
	.string "abcdefg"

It leads to exactly the behaviour i expect:

.myqwe          0x03ffe000        0x8 load address 0x00000678
 *(.myqwe)
 .myqwe         0x03ffe000        0x8 vectors.o

I wonder why defining the sections the same way does not work
for ".sdata" and for ".tdata".


C:
The sections .sdata and .tdata are empty, but also when i add
some data to it it results in the same error message.

Also, i wonder how the flags for those sections ".sdata" and
".tdata" are set.  Where do the flags come from?  Could this
influence the problem?

In main.c:
int __attribute__((section(".sdata"))) abc = 7;

The output of readelf -S shows for .sdata:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf 
Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  
0
  [ 1] .text             PROGBITS        00000000 000034 000036 00  AX  0   0  
2
  [ 2] .data             PROGBITS        00000000 00006a 000000 00  WA  0   0  
1
  [ 3] .bss              NOBITS          00000000 00006a 000000 00  WA  0   0  
1
  [ 4] .sdata            PROGBITS        00000000 00006c 000004 00  WA  0   0  
4
  [ 5] .comment          PROGBITS        00000000 000070 000012 00      0   0  
1
  [ 6] .shstrtab         STRTAB          00000000 000082 00003c 00      0   0  
1
  [ 7] .symtab           SYMTAB          00000000 000228 000090 10      8   7  
4
  [ 8] .strtab           STRTAB          00000000 0002b8 000013 00      0   0  
1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


It would be great if anybody would have a hint for me.


Best regards,
Torsten.

Re: V850, linker script problem

[Erik Christiansen]

On Sun, May 07, 2006 at 12:40:05PM +0200, Torsten Mohr wrote:
> I added another section for testing:
> 
>   .myqwe :
>   {
>     *(.myqwe)
>   } > ram AT > rom
> 
> in vectors.S:
>         .section .myqwe,"w"
> 	.string "abcdefg"
> 
> It leads to exactly the behaviour i expect:
> 
> .myqwe          0x03ffe000        0x8 load address 0x00000678
>  *(.myqwe)
>  .myqwe         0x03ffe000        0x8 vectors.o
> 
> I wonder why defining the sections the same way does not work
> for ".sdata" and for ".tdata".

A clue might be found in linking with something like:

LDFLAGS = -L /usr/local/lib/gcc/v850e/4.0.2/ -lc -lgcc
v850-ld -verbose -T your_linker_script -o test.elf your_object_files \
        $(LDFLAGS) -M > test.map

 (N.B. You're maybe not using gcc 4.0.2)

Allowing gcc to intrude into the linking process is a variable not fully
in your control. The above works for me, using the alternative "AT"
syntax in the linker script.

> 
> C:
> The sections .sdata and .tdata are empty, but also when i add
> some data to it it results in the same error message.

What happens if you rename these output sections elephant and zebra?
(The only consequential changes should be any linker script lines which
use ADDR or LOADADDR of these sections.)

Erik

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

Previously the order was (not all sections shown):
.text
.call_table_data
.call_table_text
.fini
.rodata
.rodata1
.data
.data1
.ctors
.dtors
.jcr
.gcc_except_table
.got
.dynamic
.tdata
.sdata
.rosdata

Now it is:
.text
.call_table_data
.call_table_text
.data
.data1
.sdata
.tdata
.ctors             #
.dtors             #
.gcc_except_table  #
.got               #
.dynamic
.sbss

Basically, i moved .tdata and .sdata before the sections marked with '#'.


As there is no overview of all sections available, i copied
all section names from the original V850 linker script and put
my assumptions in front of it.

I wonder why all the rela.* and rel.* get merged into the
text segment in the original.

I was searching for some of the sections with google but did
not really find an answer.

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


RAM .zdata
ROM .rozdata
ROM .interp
ROM .hash
ROM .dynsym
ROM .dynstr
ROM .rel.text
ROM .rela.text
ROM .rel.data
ROM .rela.data
ROM .rel.rodata
ROM .rela.rodata
ROM .rel.gcc_except_table
ROM .rela.gcc_except_table
ROM .rel.got
ROM .rela.got
ROM .rel.ctors
ROM .rela.ctors
ROM .rel.dtors
ROM .rela.dtors
ROM .rel.init
ROM .rela.init
ROM .rel.fini
ROM .rela.fini
ROM .rel.bss
ROM .rela.bss
ROM .rel.plt
ROM .rela.plt
ROM .init
ROM .plt
ROM .text
ROM .call_table_data
ROM .call_table_text
ROM .fini
ROM .rodata
ROM .rodata1
RAM>ROM .data
RAM>ROM .data1
ROM .ctors
ROM .dtors
ROM .jcr
ROM .gcc_except_table
ROM .got
??? .dynamic
RAM>ROM .tdata
RAM>ROM .sdata
ROM .rosdata
RAM .sbss
RAM .bss


DEBUG .stab
DEBUG .stabstr
DEBUG .stab.excl
DEBUG .stab.exclstr
DEBUG .stab.index
DEBUG .stab.indexstr
DEBUG .comment
DEBUG .debug
DEBUG .line
DEBUG .debug_srcinfo
DEBUG .debug_sfnames
DEBUG .debug_aranges
DEBUG .debug_pubnames
DEBUG .debug_info
DEBUG .debug_abbrev
DEBUG .debug_line
DEBUG .debug_frame
DEBUG .debug_str
DEBUG .debug_loc
DEBUG .debug_macinfo
DEBUG .debug_weaknames
DEBUG .debug_funcnames
DEBUG .debug_typenames
DEBUG .debug_varnames

RAM .stack

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


Erik, is the test below still needed?


Thanks for any hints,
Torsten.



> > I added another section for testing:
> >
> >   .myqwe :
> >   {
> >     *(.myqwe)
> >   } > ram AT > rom
> >
> > in vectors.S:
> >         .section .myqwe,"w"
> > 	.string "abcdefg"
> >
> > It leads to exactly the behaviour i expect:
> >
> > .myqwe          0x03ffe000        0x8 load address 0x00000678
> >  *(.myqwe)
> >  .myqwe         0x03ffe000        0x8 vectors.o
> >
> > I wonder why defining the sections the same way does not work
> > for ".sdata" and for ".tdata".
>
> A clue might be found in linking with something like:
>
> LDFLAGS = -L /usr/local/lib/gcc/v850e/4.0.2/ -lc -lgcc
> v850-ld -verbose -T your_linker_script -o test.elf your_object_files \
>         $(LDFLAGS) -M > test.map
>
>  (N.B. You're maybe not using gcc 4.0.2)
>
> Allowing gcc to intrude into the linking process is a variable not fully
> in your control. The above works for me, using the alternative "AT"
> syntax in the linker script.
>
> > C:
> > The sections .sdata and .tdata are empty, but also when i add
> > some data to it it results in the same error message.
>
> What happens if you rename these output sections elephant and zebra?
> (The only consequential changes should be any linker script lines which
> use ADDR or LOADADDR of these sections.)
>
> Erik

Re: V850, linker script problem

[Erik Christiansen]

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

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

Re: V850, linker script problem

[Erik Christiansen]

On Tue, May 09, 2006 at 10:35:32PM +0200, Torsten Mohr wrote (much
snipped):
> 
> 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.

Are you basing your work on any of the linker scripts that the v850e-gcc
build process ought to have squirrelled away in the general vicinity of
/usr/local/v850e/lib/ldscripts/ ? At least v850.x shows a suitable way
to handle .rosdata .

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

Sorry I can't advise there. Having had the luxury of a real ICE, I
haven't tried gdb or similar.

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

The only reason for suggesting objdump is that it immediately shows how
the sections chain through memory, and one starting at a wrong address
often has a cause in its predecessor. YMMV

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

Ah well, if no clues are being shaken loose, then perhaps you're right;
it's time to be satisfied that you have it working. :-)

Erik