This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: gcc on an OS less system


Should I do the below or do I have to recompile newlib with the new crt0.S
and the new syscall.c

Has any one successfully compiled gcc hosted on i686 linux for an xscale
target. I need to be able to compile C++ programs on my custom system. If so
could you please send me details of how it was done.

Thanks
Vish
----- Original Message ----- 
From: "Viswanathan Sankararam" <vishu27@cox.net>
To: <kai_ruottu@mbnet.fi>
Cc: <crossgcc@sources.redhat.com>
Sent: Saturday, October 25, 2003 9:19 AM
Subject: Re: gcc on an OS less system


> Kai,
>     So from what you say, these are the things I need to do.
> Write a crt0.S for my system similar to the redboot-crt0.s
> Write a linker script for my system similar to redboot.ld
> Write a syscalls.c similar to redboot-syscalls.c
> Write a specs file similar to redboot.specs
> Use this new specs file with gcc when compiling my c++ files using
> the -specs option  with gcc.
>
> Am I right in concluding this, and would this override the syscalls
already
> compiled into libc.a?
>
> Thanks
> Vish
> ----- Original Message ----- 
> From: "Kai Ruottu" <karuottu@mbnet.fi>
> To: "Viswanathan Sankararam" <vishu27@cox.net>
> Cc: <crossgcc@sources.redhat.com>
> Sent: Friday, October 24, 2003 6:33 AM
> Subject: Re: gcc on an OS less system
>
>
> > "Viswanathan Sankararam" <vishu27@cox.net> wrote:
> >
> > >     I have an installation of the gnupro tools for xscale. I am trying
> to
> > > run C++ programs on a system which has no OS. From what I understand,
I
> have
> > > to write a linker script that corresponds to my system and also
rewirte
> the
> > > crt0.S from newlib to do the initialization for my system. I also
> understand
> > > that I need to provide some OS stubs so that the libc.a functions do
not
> > > call the already build in system calls.
> > >     The question is how will I override the system calls that come
with
> > > libc.a with my implementation of the syscalls. Do I just remove
> syscalls.o
> > > from the archive and add mine. Would that work?
> >
> >  The 'newlib/libc/sys/arm' should have all the routines which glue the C
> library
> > to the Angel/Demon environment. If you see what objects would be built
> into your
> > $build/arm-elf/newlib/libc/sys/arm, by spying the Makefile.in etc., and
> then
> > remove them from 'libc.a', then you will have quite a plain vanilla
> 'libc.a' with
> > pure generic 'arm-elf' stuff, suitable for anything else...  The
> 'syscalls.o' is not
> > enough to be removed...
> >
> >  The sources there will then help when trying to write equivalents to
> them. That
> > you must do for all sanity...
> >
> >  I remember this being discussed here earlier and definitely there are
> other
> > supported target platforms like 'RedBoot' for ARM/XScale, not only the
> Angel
> > and Demon monitors...
> >
> >  OOPS, you wrote about GNUPro... This isn't the same as plain vanilla
> newlib,
> > its libgloss has 'arm' subdir and there:
> >
> > kai@mt586kr:/home3/src/gnupro-xscale-20020523/src/libgloss > ls arm
> > Makefile.in         coff-redboot.specs  elf-pid.specs
> redboot-syscalls.c
> > coff-iq80310.specs  configure           elf-redboot.ld      syscall.h
> > coff-pid.specs      configure.in        elf-redboot.specs
> > coff-redboot.ld     elf-iq80310.specs   redboot-crt0.S
> >
> > so what I wrote was bullshit... Maybe your 'syscalls.o' was made from
this
> > 'redboot-syscalls.c'... Anyhow your problem requires someone who knows
> > the organization here. Although I seem to have my 'lib' produced from
the
> > GNUPro-stuff:
> >
> > kai@mt586kr:/home2/usr/local/arm-elf/lib > ls
> > aeb-1               fpu                 libg.a
> redboot-syscalls.o
> > armpid              interwork           libm.a              redboot.ld
> > be                  iq80310.specs       libnosys.a
redboot.specs
> > cma222              ldscripts           pid.specs           thumb
> > crt0.o              libc.a              redboot-crt0.o
> >
> > kai@mt586kr:/home2/usr/local/arm-elf/lib > cat redboot.specs
> > %rename link                old_link
> >
> > *link:
> > -T redboot.ld%s -Ttext 0x20000 %(old_link)
> >
> > *startfile:
> > crti%O%s crtbegin%O%s %{!pg:redboot-crt0%O%s} %{pg:redboot-crt0%O%s}
> redboot-
> > sys
> > calls%O%s
> >
> >  I'm not sure how these extra 'specs' should be used to override the
> defaults... But this
> > seems to replace the link and startfile specs with new specs which force
> to use these
> > new objects and then not take any symbols, these have in them, with the
> same name
> > from the 'libc.a' with the Angel/Demon routines...
> >
> >  Ok, here are the clues and the rest is your problem :-)
> >
> > > Also is there any thing else that I would need to do the get the C++
> > > programs to work on this bare system.
> >
> >  The C++ programs should work, the crti.o and crtbegin.o come with GCC,
so
> getting
> > crt0.o and syscalls.o to ported to your own system should be enough. The
> supported
> > systems in the gnupro-newlib sources should give examples to mimic...
> >
> > > One more thing. What is the difference between newlib and libgloss.
Does
> > > newlib use libgloss or are they two separate C library implementations
> and I
> > > dont have to deal with libgloss if I am going to use newlib.
> >
> >  The libgloss usually has the missing (from libc.a) target dependent
> routines in a
> > separate (glue) library. For one 'libc.a' one can have several different
> glue libs
> > for different boards using the same CPU. With ARM there has been only
one
> > supported target system and so the glue library has been integrated into
> the
> > 'libc.a', which is basically wrong...
> >
> > Cheers, Kai
> >
> >
> > ------
> > Want more information?  See the CrossGCC FAQ,
> http://www.objsw.com/CrossGCC/
> > Want to unsubscribe? Send a note to
> crossgcc-unsubscribe@sources.redhat.com
> >
>
>
> ------
> Want more information?  See the CrossGCC FAQ,
http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to
crossgcc-unsubscribe@sources.redhat.com
>


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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