gcc on an OS less system

[vishu27@cox.net]

Is there any way I can confirm if this is working. When I run an object created with the -specs=redboot.specs option with the arm simulator xscale-elf-run, It hangs saying 

sim: unknown SWI encountered - 0 - ignoring

Thanks
Vish

> 
> From: "Kai Ruottu" <karuottu@mbnet.fi>
> Date: 2003/10/29 Wed AM 03:09:01 EST
> To: <crossgcc@sources.redhat.com>
> CC: "Viswanathan Sankararam" <vishu27@cox.net>
> Subject: 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
> 
> 


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