Re: Setting up Newlib for a Sparc-elf configured GCC

[Jeff Johnston <jjohnstn at redhat dot com>]

MichaelMontcalm wrote:
> Hi All,
>
> I've been in the process of setting up a new install of GCC recently, and am
> nearly done. The only thing I do not understand how to do is finish the
> setup of Newlib before making my own crt0.o file.
>
> I've currently installed binutils 2.17 and gcc 4.2.0 successfully (after
> nearly putting my laptop through the wall a few times). I've also installed
> gmp and mpfr (in case I need to move to a newer version of GCC in the
> future). I've been following the Wiki
> (http://wiki.osdev.org/GCC_Cross-Compiler) on how to do this, but have
> gotten stuck on the porting Newlib section
> (http://wiki.osdev.org/Porting_Newlib).
>
> The part I'm lost at is right near the beginning, where it requires you to
> make the system calls. It shows a large set of code, but gives no
> explanation as to what I'm supposed to do with it. In my
> newlib-1.16.0/libgloss folder I do have several of the commands mentioned in
> the wiki, but I'm unsure what to do now. Do I need to edit the ones there
> and create files for the entries that do not exist? Are these files
> different because I configured newlib for sparc-elf as opposed to x86?
>
>   
The code that is documented are minimal stubs that you would put into 
your libgloss library which would reside in libgloss/YOUR_PLATFORM 
(which in your case is libgloss/sparc and already exists).  The stubs 
are already supplied for you in libnosys which gets built as part of 
libgloss.  With the exception of sbrk, those syscall stubs usually 
return a failure return code and may set errno appropriately.  The 
examples given are written in C so they will work on any platform.  To 
use the libnosys library, you simply add -lnosys to your link. 

If you look at the libgloss/sparc directory you will see there are 
already a number of BSP (Board Support Packages) supplied.  Each has its 
own .ld script which set  the libraries to automatically link to so the 
user just specifies -Txxxx.ld on the compile/link statement.  One can 
add -lnosys inside an ld script GROUP command to default any missing 
syscalls to the default stubs.  If you have a sparc board that isn't 
already provided, you should probably look at copying a BSP that is 
close and change what you need and add it to Makefile.in.  The end-user 
would just specify -T{your_ld_script_name}.ld  If an existing BSP 
already matches your board, then you have nothing to do.  An end-user 
would specify -T{existing_ld_script_name}.ld when compiling/linking the 
application.

With the stubs documented, plus a crt0 (usually sets up the stack 
register, clears the bss, calls main, and calls exit or _exit when main 
returns), you have enough to link and run C programs using newlib.  As 
previously stated, most calls fail so the C routines that use them under 
the covers will also return failure (e.g. fopen() will return NULL).  If 
you need to have some of the functionality work rather than fail, then 
you'll want to supply your own versions of the syscalls.  For example, 
some boards supply read/write syscalls that receive and send data to the 
serial port to support the std stream file descriptors (e.g. printf).  
It all depends on the board and what you want to support.  If you have 
an OS, then you'll want to hook into the real syscalls provided by the OS.

If running under a simulator, you would want to invent a special trap or 
insn sequence that the simulator can recognize.  It doesn't have to work 
on the real hardware.  The simulator is then written to recognize the 
special trap or insn sequence you have set up and simply calls local C 
library functions to do the work.

Hopefully, that clarifies a bit.

-- Jeff J.
> Any help would be appreciated!
>