porting newlib

[Matt Broadstone]

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