OSDev.org

OK, I'm getting to that stage where I'm almost ready for release of the newest version of my OS. There's just one problem: I promised a library for developers would come with this release.

For those who don't know already, I've just converted my OS to C++ (still doesn't have a lot of the old functionality, but it works). Now, I'm planning on porting newlib so that people can write their own programs for my OS using ANSI C code.

What support functions do I need in my kernel? And how are these linked in to the newlib?

A few projects have successfully ported Newlib, And there is probably quite a few topics on the forum discussing it.

Try using the forum search... Good luck.

newlib is incredibly easy to port actually

all you need is your own runtime library (crt0) and a compiled version of newlib in your ld path

when i ported it to my OS i just used a very bare-bones crt0 (syscalls and start routine), and filled in the blanks when i got linker errors for stuff newlib was trying to pull in

So, basically, I link in a compiled newlib to my programs, then when LD complains of unrecognized symbols I just implement them?

Where can I find an already-compiled newlib (for ELF)? Or do I have to build it myself?

you should build it with your cross-compiler if you have one
also, remember to install the libraries in your cross-compiler-specific path, so that you dont accidentally overwrite something

there's also a couple of stubs in the newlib docs that might help you get an idea of how some unimplemented (in your OS) functions should look
basically, they just throw an error no matter what

I made these patches last year for a project called "MortOS".. It should show you what kind of changes had to be made when porting newlib.

http://www.osdev.org/phpBB2/download.php?id=55

Another possible way to find information is by typing: "Porting newlib" into Google..

Am downloading source now... Once done will feed to my cross-compiler in Cygwin and cross my fingers.

By the way, does the newlib do stuff like the hard drive access for the file i/o or do I have to do that and provide access to it via a syscall? If via the syscall, how are they called?

Google for "newlib", first hit is "The Newlib Homepage", its navbar containing "Info - News - Download - Mailing List - FAQ - Docs", first entry of the category being called Red Hat newlib C Library Documentation, which has 13 chapters, chapter #12 being named "System calls"...

OK, I've built a newlib (with none of my own syscalls added) just to see what happens when I try to link. A simple "Hello World" program doesn't work at all - I get 'undefined reference to printf'...

So now my only problems are how to integrate my versions of the syscalls, and how to get it to work with my programs. Any ideas?

OK, fixed the printf problem, now I only have to somehow get the syscalls into the library.

Does anyone know of a really good tutorial out there?

As soon as I get this done, I'm going to draft a tutorial for porting newlib to your own OS so that others don't have to go through what I'm going through now

I found a tutorial about this:
http://www.embedded.com/story/OEG20011220S0058

Am I able to just modify the files in the newlib/syscalls folder to match my code?

I don't know, but I think you should look in the libgloss directory.

Actually, I found this post: libc port

It seems I've already done almost everything necessary...

Edit: I have done everything The only problem now is, nothing happens when I run the program. I probably will need to poke some bytes to the screen on each call. Thanks for all the help, guys!

Note that printf() is a highly, HIGHLY monolithic and complex function. It uses fopen/fwrite etc (buffered i/o) so it requires the syscall "sbrk" to be implemented first and to work correctly. Also it requires the file descriptors stdin/out/err to already be initialised to descriptor values 0/1/2 etc.

Probably worth getting fopen/fwrite to work first, or sprintf into a string and call your syscall write() direct first.

Common stumbling point with newlib - make sure **environ is defined - NULL will do but make sure it's actually there somewhere - you won't get any linker errors if it's not but the library will fall over.

JamesM