Re: gcc on an OS less system

["Viswanathan Sankararam" <vishu27 at cox dot net>]

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