This is the mail archive of the mailing list for the newlib project.

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: Setting up Newlib for a Sparc-elf configured GCC

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
( on how to do this, but have
gotten stuck on the porting Newlib section

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 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!

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