[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openrisc] Linking problems



You should use -nostdlib, but specify also -lm, to include libgcc.a
library:

or32-uclinux-gcc -DPACKAGE=\?or1ksimtest\? -DVERSION=\?1.3\? -I.
-I.-I-/support  -Wall -g -mhard-div -c fft.c
or32-uclinux-gcc -Wall -g -mhard-div -o fft -T.//default.ld except.o
fft.o support/libsupport.a -L<path-to-libgcc.a> -lgcc

path-to-libgcc.a is
<gcc-instalation-folder>/lib/gcc-lib/or32-uclinux/3.1/

Simon


javier_castillo_villar@yahoo.es wrote:
> I am compiling a program using or32-uclinux-gcc against ukernel and then
> I link it using the default.ld script included in /testbench.
> To compile it I use these orders that I copy from the testbench
> makefile. The only difference is I donīt use -nostdlib because I want my
> program can
> use float types and rand function. My program is a very simple fft
> calculation but its use floats operations so I have to include the
> standards libs.
>  
> or32-uclinux-gcc -DPACKAGE=\?or1ksimtest\? -DVERSION=\?1.3\? -I. -I.
> -I-/support  -Wall -g -mhard-div -c fft.c
> or 32-uclinux-gcc -Wall -g -mhard-div -o fft -T.//default.ld except.o
> fft.o support/libsupport.a
>  
> Everything goes ok.
>  
> But when I tried to simulate the output I found that my reset vector was
> in 0x130 position instead od 0x100.
> I looked at 0x0 position and I found a ___stdio_close_all label and some
> code. The length of the code in position 0x0 was 0x30 so my reset vector
> begans 
> 0x30 positions below and the simulator didnt work.
>  
> When I use or32-uclinux-readelf to read the binary I found a line like
> this:
>  
> Num:   Value           Size   Type          Bind       Vis
> Ndx     Name
> 195     00000000     0        NOTYPE    WEAK   DEFAULT    UND
> ___stdio_close_all
>  
> The only way I found to do my program works it modify the org 0x100
> directive in except.S file to make reset vector begins in 0xD0 position,
> when I do it the reset vector is located in 
> 0xD0+0x30=0x100 and the program works.
>  
>  
> I dont know it this can be a uclibc port bug or I have to add something
> to default.ld file.
>  
>  
>  
> Thanks very much
>  

javier_castillo_villar@yahoo.es wrote:
> 
>   Hi:
> 
>    The problem is the function called __stdio_close_all. It was located
> in the 0x0 position. When I use the or32-uclinux-readelf -a I can see in
> one line:
> 
>  Value         Size  Type      Bind    Vis          Ndx  Name
>  00000000      0  NOTYPE  WEAK DEFAULT  UND  ___stdio_close_all
> 
> How can I solve this?
> 
> Thanks
> 
> ----- Original Message -----
> From: javier_castillo_villar@y...
> To: openrisc@o...
> Date: Wed, 13 Nov 2002 16:10:56 -0100
> Subject: [openrisc] Linking problems
> 
> >
> >
> >
> >   Hello:
> >
> >     Iīve been linking programs against ukerner included in the
> > testbench directory of or1ksim.
> >    When I compile a program using float operations I send the ctors
> > and dtors sections to RAM memory using the default.ld script. But
> > when I try to run my program in the simulator I found this in the
> > 0x0
> > position:
> >
> > i=0 :: label: ___stdio_close_all |9c21fffc l.addi r1,r1,-4
> > i=4 :: d4014800 l.sw 0x0(r1),r9
> > ....
> > ....
> > ....
> > i=2c :: 9c210004 l.addi r1,r1,0x4
> >
> >
> > Because of this my reset vectors begins in 0x1300 instead of 0x100.
> > I think I should modify the default.ld script but I donīt know how
> >
> > Thanks
> >
> --
> To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml