porting newlib

Matt Broadstone mbroadst@bryant.edu
Tue May 11 23:28:00 GMT 2004

Great. Just one more question, you said to look at libgloss/libnosys, does
that mean that I should be implementing this all in the libgloss directory?
Or do you mean just to use those as examples in my libc/sys/myos dir? 


Matt Broadstone
Tel: (401) 232-4498
Cell: (301) 641-6893
E-mail: mbroadst@bryant.edu 

-----Original Message-----
From: Jeff Johnston [mailto:jjohnstn@redhat.com] 
Sent: Tuesday, May 11, 2004 6:37 PM
To: Matt Broadstone
Cc: newlib@sources.redhat.com
Subject: Re: porting newlib

Matt Broadstone wrote:
> Well you see, the reason I chose to try using newlib is because the OS
> is intended for is non-*ix (I probably would have used glibc otherwise
> right?) As for right now I would simply like to implement the basic
> syscalls, and add new ones from there. So what I have done so far is:
> - make a new directory in libc/sys for the os
> - add a sys directory inside of it with a "syscall.h"
> - add files to the previous directory (libc/sys/my-os) implementing the
> basic syscalls (open.c, read.c, write.c - you get the idea, but not
> exec.c, fork.c because they are not implemented in this OS in favor of
> methods, I am assuming since I set syscall_dir to syscalls it will fill in
> stub for these that I do not implement?)

This is mostly correct, however, you won't get default stubs.  If they don't

apply you should put in your own default stubs for the missing syscalls (see
libgloss/libnosys directory).  They are relatively simple.

> - modify configure.host to recognize my os, set the sys_dir to that
> and syscall_dir to ??? (syscall_dir=syscalls?)

Yes.  Set syscall_dir=syscalls.  Make sure your syscalls start with an 
underscore (e.g. open.c should implement _open).

> that seems to be as much as I have gotten. I am completely glossing over
> libgloss right now just to get newlib working. Am I on the right track?
> there any specific files I am forgetting to change? 

You won't need to alter libgloss.  You are on the right track.

> _______________________________
> Matt Broadstone
> Tel: (401) 232-4498
> Cell: (301) 641-6893
> E-mail: mbroadst@bryant.edu 
> -----Original Message-----
> From: Jeff Johnston [mailto:jjohnstn@redhat.com] 
> Sent: Tuesday, May 11, 2004 5:50 PM
> To: Matt Broadstone
> Subject: Re: porting newlib
> Matt Broadstone wrote:
>>Thank you so much, very informative. The specific port I am trying to
>>accomplish is for an OS that runs on ix86, so I'm not sure that I need to
> do
>>much regarding the machine dir, setjmp etc. and in which case I think I do
>>need to work specifically with the sys_dir, and sys_call dirs as the port
> is
>>an os port not an architecture port. I understand this is a rather strange
>>task, but if you have any insight it'd be much appreciated. 
> Yes, you are right.  You have to add a sys directory.  At a minimum, you
> have to 
> supply the assembly code for the newlib syscalls on your OS.  This is a 
> relatively small set (see the libgloss/fr30/syscalls.c for the set).  If
> ever feel you might add other platforms, you can do like sys/linux did and
> have 
> a machine/i386 directory.  This allows you to add other platforms in the
> future.
> Now, if you have a relatively robust OS, you may want more than the basic
> newlib 
> syscall set.  If your syscall set is similar to linux, you have the option
> of 
> stealing code from the sys/linux directory for POSIX routines that use the

> syscalls.  Note that sys/linux is LGPL and if you take code from there
> library will end up LGPL too.  Vanilla newlib is BSD-like.  The licensing
> issue 
> may or may not sway your decision.
> Depending how similar your OS is to Linux regarding types of syscalls, you
> could 
> try an experiment and change the syscall code in 
> libc/sys/linux/machine/i386/syscall.h.  Then try building newlib for 
> i686-pc-linux-gnu (configure with --with-newlib).  Link your executable
> try 
> it out on your OS.  If this works and you are ok with having an LGPL
> license, 
> there might be an opportunity to share the code which will save you
> -- Jeff J.
>>Matt Broadstone
>>Tel: (401) 232-4498
>>Cell: (301) 641-6893
>>E-mail: mbroadst@bryant.edu 
>>-----Original Message-----
>>From: newlib-owner@sources.redhat.com
>>[mailto:newlib-owner@sources.redhat.com] On Behalf Of Jeff Johnston
>>Sent: Tuesday, May 11, 2004 4:20 PM
>>To: Matt Broadstone
>>Cc: newlib@sources.redhat.com
>>Subject: Re: porting newlib
>>Matt Broadstone wrote:
>>>When the build process builds for say "arc" (for example), the defined
>>>syscall_dir is the directory "syscalls" in "libc" which are all stubs,
>>>correct? However there is another file called "syscalls.c" inside the arc
>>>sys_dir. I have tried to look into what was done for linux, but linux has
>>>nothing to do with syscalls.... I am very lost here obviously, but there
>>>seems to be no documentation regarding this stuff? Please excuse my
>>>ignorance :)
>>   A basic port needs to alter a number of files and add some directories.
>>   1. Add a subdirectory to the newlib/libc/machine directory for your
>>      In this directory you need to have a setjmp/longjmp implementation.
>>      is required because setjmp/longjmp usually is assembler.  Look at
> the
>>      libc/machine/fr30 directory and copy/modify the files in there.
>>   2. Edit newlib/libc/include/machine/ieeefp.h
>>      This defines the ieee endianness for your platform.  The compiler
>>      be defining something that identifies your machine.  In some cases,
>>      endianness may be a compiler-option so you may have to check another
>>      define in addition to your platform identifier.  See examples in the
>>      file.
>>   3. Edit newlib/libc/include/machine/setjmp.h
>>      You need to specify the setjmp buffer characteristics to match up
> with
>>      your setjmp/longjmp implementation.  This is just the size of the
>>      setjmp buffer.  See file for examples.
>>   4. Edit newlib/libc/include/sys/config.h
>>      This has various defines as needed.  Mostly, it defines some max
>>      values.  There are defaults that may apply to your platform in which
>>      you needn't do anything.
>>   5. Edit configure.host
>>      You need to add your configuration so newlib can recognize it.  You
>>      specify your new machine directory for your platform via the
>>      variable.  If needed, you can add special newlib compile flags.  The
>>      sys_dir is for OS stuff so you won't need to alter that.  Older
>>      used the sys_dir to implement syscalls but this is not correct and
> is
>>      a historical nuisance.  The syscall_dir is a choice, but I recommend
>>as a
>>      default to specify syscall_dir=syscalls. Read the comments in
>>      newlib/libc/include/reent.h for an explanation of choices.
>>   6. Add a machine subdirectory to libgloss
>>      You need to add a bsp for your platform.  This is the minimum set of
>>      syscalls needed by newlib and any linker scripts needed.  This
> varies
>>      from board to board (it can also be a simulator).  See the
>>      mn10300 or fr30 for examples. You will need
>>      to edit configure.in and regenerate configure so it will build your
>>      new files.  By default you get libnosys which gives you a set of
>>      default syscall stubs.  The majority of the stubs just return
> failure.
>>      You still need to supply an __exit routine.  This can be as simple
> as
>>      generating an exception to stop the program.
>>   7. Possibly override header files
>>      If you need to override any default machine header files, you can
>>      add a machine directory to newlib/libc/machine/<YOUR_MACHINE_DIR>
>>      Header files in that subdirectory will overwrite the defaults found
>>      in newlib/libc/include/machine.  You will likely not need to do
> this.
>>   This assumes you have already handled adding your new configuration to
>>top directory files.
>>   Now linux is a different animal.  It is an OS that has an extensive set
>>syscalls.  If you look in the newlib/libc/sys/linux directory, you will
> find
>>number of syscalls there (e.g. see io.c).  There is a set of basic syscall
>>macros that are defined for the particular platform.  For the x86, you
> will
>>these macros defined in newlib/libc/sys/linux/machine/i386/syscall.h file.
>>the moment, linux support is only for x86.  To add another platform, the 
>>syscall.h file would have to be supplied for the new platform plus some
>>platform-specific files would need to be ported as well.
>>   I hope this helps.
>>-- Jeff J.

More information about the Newlib mailing list