Re: gcc on an OS less system

["Kai Ruottu" <karuottu at mbnet dot fi>]

"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