porting newlib

Wed May 12 12:00:00 GMT 2004

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