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?
Tel: (401) 232-4498
Cell: (301) 641-6893
From: Jeff Johnston [mailto:firstname.lastname@example.org]
Sent: Tuesday, May 11, 2004 6:37 PM
To: Matt Broadstone
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: email@example.com
> -----Original Message-----
> From: Jeff Johnston [mailto:firstname.lastname@example.org]
> 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
>>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
>>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
> a machine/i386 directory. This allows you to add other platforms in the
> Now, if you have a relatively robust OS, you may want more than the basic
> syscall set. If your syscall set is similar to linux, you have the option
> 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
> may or may not sway your decision.
> Depending how similar your OS is to Linux regarding types of syscalls, you
> 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
> it out on your OS. If this works and you are ok with having an LGPL
> there might be an opportunity to share the code which will save you
> -- Jeff J.
>>Tel: (401) 232-4498
>>Cell: (301) 641-6893
>>[mailto:email@example.com] On Behalf Of Jeff Johnston
>>Sent: Tuesday, May 11, 2004 4:20 PM
>>To: Matt Broadstone
>>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
>> 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
>> 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
>> 3. Edit newlib/libc/include/machine/setjmp.h
>> You need to specify the setjmp buffer characteristics to match up
>> 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
>> a historical nuisance. The syscall_dir is a choice, but I recommend
>> 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
>> 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
>> You still need to supply an __exit routine. This can be as simple
>> 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 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
>>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
>>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