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


"Viswanathan Sankararam" <vishu27@cox.net> wrote:

> 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

 Something like that, although just removing the current 'syscalls.o'
(the original for Angel/Demon) from the 'libc.a' and substituting it
with your own self-made one, and doing the same with the 'crt0.o'
could be simpler.  Editing the default 'specs' (normally in the
'$prefix/lib/gcc-lib/xscale-elf/$gcc-version' in a 'xscale-elf' target
toolchain) and putting the defaults there, shouldn't be hard either.

 The RedHat's docs for GNUPro ('http://www.redhat.com/manuals'
or something) and the 'embed' one should tell about the calling
conventions for ARM etc., maybe the docs coming with the XScale
distributions also tell about these things...  What becomes Redboot,
the RedHat's eCos (their free RTOS) -docs would tell more.  The
asm-wrapper in the 'redboot-syscalls.c' could require some consultation
from the docs.

> Use this new specs file with gcc when compiling my c++ files using
> the -specs option  with gcc.

 Haven't tried this option, but maybe this is just the one requires for
this kind of case... The eCos-docs could be expected to describe how
one uses the Redboot instead of Angel/Demon...

> Am I right in concluding this, and would this override the syscalls already
> compiled into libc.a?

 I think you are right, but replacing, with 'xscale-elf-ar r', the existing 'syscalls.o' object 
with your own:

  commands:
   d            - delete file(s) from the archive
   m[ab]        - move file(s) in the archive
   p            - print file(s) found in the archive
   q[f]         - quick append file(s) to the archive
   r[ab][f][u]  - replace existing or insert new file(s) into the archive
   t            - display contents of archive
   x[o]         - extract file(s) from the archive

and replacing the crt0.o and using your own linker script to tell
the memory map etc., should work too.  It seems that the 'endfile'
spec in 'specs' could be the best place to put the required
'-T link_script%s' option (the '%s' causes it being searched from
the usual library paths), so that it is quite late on the link command
line.

 BTW, I had only the newlib-1.10.0 sources to be seen last, but when
now seeing the 1.11.0 ones, ARM seems to have an entry in libgloss
and the same Redboot-stuff there as with the GNUPro/XScale
distribution.... So the difference between a toolchain built from usual
newlib-stuff and a toolchain built from the XScale-sources isn't that
big any more. Quite a lot (Intel-) ARM-specific support stuff included
into the Intel/RedHat XScale GNUPro-sources is however still missing
from the plain vanilla newlib-1.11.0.

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


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