This is the mail archive of the newlib@sources.redhat.com 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: porting newlib


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. 

I have read the reent.h before and, correct me if I am wrong, but here is
what I think I understand so far. I need to supply the code for (most of)
the 17 base system calls (open, write, read etc.) in order to allow the
generic libc that newlib builds to run on this new os. So far I have sort of
been trying to emulate what's been done in the "sys" dir's (sysmec primarily
because the other ones are all written in asm, which I just don't know heh).
Thanks.

_______________________________

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.



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