Re: porting newlib

[Jeff Johnston <jjohnstn at redhat dot com>]

Matt Broadstone wrote:
> 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? 

Just copy them when you are creating default stubs for non-existent syscalls.

> _______________________________
>
> 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
>
> this
>
> > 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
>
> kill.c,
>
> > exec.c, fork.c because they are not implemented in this OS in favor of
>
> other
>
> > methods, I am assuming since I set syscall_dir to syscalls it will fill in
>
> a
>
> > 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
> the 
> libgloss/libnosys directory).  They are relatively simple.
>
>
> > - modify configure.host to recognize my os, set the sys_dir to that
>
> folder,
>
> > 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?
>
> Are
>
> > 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
>
> you
>
> > 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
>
> your 
>
> > 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
>
> and
>
> > 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
>
> effort.
>
> > -- 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 :)
> > >
> > >
> > > Matt,
> > >
> > >  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
> > > platform.
> > >     In this directory you need to have a setjmp/longjmp implementation.
> > > This
> > >     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
> > > should
> > >     be defining something that identifies your machine.  In some cases,
> > > the
> > >     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
> > > case
> > >     you needn't do anything.
> > >
> > >  5. Edit configure.host
> > >     You need to add your configuration so newlib can recognize it.  You
> > > should
> > >     specify your new machine directory for your platform via the
> > > machine_dir
> > >     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
> > > platforms
> > >     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
> > > the 
> > > top directory files.
> > >
> > >  Now linux is a different animal.  It is an OS that has an extensive set
> > > of 
> > > syscalls.  If you look in the newlib/libc/sys/linux directory, you will
> >
> > find
> >
> >
> > > a 
> > > 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
> >
> >
> > > find 
> > > these macros defined in newlib/libc/sys/linux/machine/i386/syscall.h file.
> > > At 
> > > 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
> > > other 
> > > platform-specific files would need to be ported as well.
> > >
> > >  I hope this helps.
> > >
> > > -- Jeff J.