OSDev.org

I'm constructing a Library OS where the application and kernel are linked together. I'd like to be able to link with libc and use libc functionality. For example, I'd like printf to call through to my console to actually make the write. My understanding is that this requires a port of libc where I implement whichever "system calls" I need. For this do I simply need to port something like newlib? Or do I need to build an entire OS specific toolchain? How about if I want to use c++ and have support for the c++ standard library and exceptions etc. ?

System calls are usually done by interrupts , you register an interrupt handler at any interrupt of your choice as long as it's not registered for something else and use it to pass system calls and so on...(HINT: Unix uses interrupt 0x80)

for a C library , you can write one yourself or use premade library's such as Newlib and so on..
the samething apply on C++ , and you need to write some runtime depending on the compiler you use I guess...

and an OS Specific Toolchain is usually needed so you can have a flat compiler to build on , especially if you want to make a self-hosted Operating System )))

I'm newbie at this so wait for a professional answer )))

Neoncore wrote:System calls are usually done by interrupts , you register an interrupt handler at any interrupt of your choice as long as it's not registered for something else and use it to pass system calls and so on...(HINT: Unix uses interrupt 0x80)

This doesn't make a lot of sense in my system. Since everything is linked together, a syscall can be implemented as a function call.

Neoncore wrote: and an OS Specific Toolchain is usually needed so you can have a flat compiler to build on , especially if you want to make a self-hosted Operating System )))

What does this mean? Flat compiler? Self-hosted Operating System?

Basically, if you use newlib, the components are:

Kernel Side
1. Kernel - that provide all the functionalities
2. Kernel Services - functionalities exposed for application
3. Kernel API - the interface and datatypes specification, including calling method and convention, some example are INT, SYSENTER, SYSCALL
User - Library
4. newlib - compile directly
5. libgloss - the code to do the actual calling which match (3)
6. extra library to interact with additional kernel functionalities
User - Application
7. Executable - that uses (4) and (6)
8. Extra shared object - that also uses (4) and (6)

Things should be similar with other libc variant.

On the tool-chain, you should check the wiki.

dschatz wrote:I'm constructing a Library OS where the application and kernel are linked together.

I just noticed that, in this case, your libgloss may call the kernel directly using regular function call.

dschatz wrote:

Neoncore wrote:System calls are usually done by interrupts , you register an interrupt handler at any interrupt of your choice as long as it's not registered for something else and use it to pass system calls and so on...(HINT: Unix uses interrupt 0x80)

This doesn't make a lot of sense in my system. Since everything is linked together, a syscall can be implemented as a function call.

Neoncore wrote: and an OS Specific Toolchain is usually needed so you can have a flat compiler to build on , especially if you want to make a self-hosted Operating System )))

What does this mean? Flat compiler? Self-hosted Operating System?

by saying a flat compiler , or a cross compiler or what ever you call it .. it's a compiler built to compile softwares to your Operating system platform...

self hosted Operating System is a system that can host it self by compiling it's own kernel and application without usage of a host operating system such as linux.

bluemoon wrote:

dschatz wrote:I'm constructing a Library OS where the application and kernel are linked together.

I just noticed that, in this case, your libgloss may call the kernel directly using regular function call.

Most newlib ports I see modify newlib/libc/sys
What requires libgloss to be modified?

Also, what if I want c++ rtti and exception support? Do I need to port a separate library? Can I use libgcc and libsupc++? Should I just go through the OS specific toolchain to port those or is there a simpler way?

Answers to virtually all your questions are on the wiki. Did you, by chance, miss that huge OSDev.org Wiki link at the top of the page?

I did not, could you point me to where in the wiki my questions are answered? I've looked and was not able to find sufficient answers.

Also, what if I want c++ rtti and exception support? Do I need to port a separate library? Can I use libgcc and libsupc++? Should I just go through the OS specific toolchain to port those or is there a simpler way?

http://wiki.osdev.org/C%2B%2B_Exception_Support

For this do I simply need to port something like newlib? Or do I need to build an entire OS specific toolchain? How about if I want to use c++ and have support for the c++ standard library and exceptions etc. ?

http://wiki.osdev.org/How_kernel,_compi ... k_together
http://wiki.osdev.org/Porting_Newlib
http://wiki.osdev.org/OS_Specific_Toolchain


I hope reading through all those pages isn't too much for you?

Griwes wrote:

Also, what if I want c++ rtti and exception support? Do I need to port a separate library? Can I use libgcc and libsupc++? Should I just go through the OS specific toolchain to port those or is there a simpler way?

http://wiki.osdev.org/C%2B%2B_Exception_Support

For this do I simply need to port something like newlib? Or do I need to build an entire OS specific toolchain? How about if I want to use c++ and have support for the c++ standard library and exceptions etc. ?

http://wiki.osdev.org/How_kernel,_compi ... k_together
http://wiki.osdev.org/Porting_Newlib
http://wiki.osdev.org/OS_Specific_Toolchain


I hope reading through all those pages isn't too much for you?

First of all, you're being rude. If you feel that I'm wasting your time, then you shouldn't be responding to the thread in the first place. I feel like this shockingly prevalent attitude really hurts the osdev community.

Second of all, either you failed to read my questions (and the surrounding context) or you lack understanding of what is in those wiki articles. My question regarding c++ support is in the context of having a libc (say newlib) port. I wonder if it is sufficient to just use my host libgcc and libsupc++, this isn't answered by your link. The other questions you've quoted are in the context of direct support for libc within my kernel address space. The only really relevant link is the second one which simply explains how to port newlib, though it clearly conflicts with the OS_Specific_Toolchain wiki article which seems to be another way to do this (hence my following questions).

No, I ain't being rude. You are just failing your searching skills test.

I wonder if it is sufficient to just use my host libgcc and libsupc++, this isn't answered by your link.

What would be the point of porting libraries, if you could "just use" host libraries? If you cannot understand why you need to port something to your (most probably not having full POSIX support) OS, then you're not ready for being here.

The other questions you've quoted are in the context of direct support for libc within my kernel address space.

Seriously? Porting to kernel space is identical to porting to user space - you need to implement exact same functions defined by library's documentation; the only difference would be to use direct calls instead of syscalls (or no difference in case of "hard" microkernel).

The only really relevant link is the second one which simply explains how to port newlib, though it clearly conflicts with the OS_Specific_Toolchain wiki article which seems to be another way to do this (hence my following questions).

C++ Exception Support isn't answering the question how to use C++ exceptions in kernel space? Oh well. Anyway, "another way" and "conflicting way" are two distinct things.

I feel like this shockingly prevalent attitude really hurts the osdev community.

Hey, I'm not the one asking questions that have been answered already - here and on wiki, and in the rest of the internet.

Griwes wrote:

I wonder if it is sufficient to just use my host libgcc and libsupc++, this isn't answered by your link.

What would be the point of porting libraries, if you could "just use" host libraries? If you cannot understand why you need to port something to your (most probably not having full POSIX support) OS, then you're not ready for being here.

I'm asking if I even need to port them in the first place. Not all libraries require full POSIX support. My host OS and target OS both run the same architecture, so perhaps the unwind library could be the same? I didn't see that addressed in anything you linked.

The other questions you've quoted are in the context of direct support for libc within my kernel address space.

Seriously? Porting to kernel space is identical to porting to user space - you need to implement exact same functions defined by library's documentation; the only difference would be to use direct calls instead of syscalls (or no difference in case of "hard" microkernel).

And other differences like crt0...

By POSIX support I meant something that would allow you to use exactly same environment as on your host. And: things like fopen() needs to make calls to kernel; how would you do it on your custom kernel without modifications of your host library?

And about crt0 - you are already linking your kernel without startup files, aren't you?


One last time: CRT needs to make syscalls in certain parts of it, including malloc()/free() (think of allocating a page for a process) - how could that, inherently OS-specific call, be made without instructing the library how to do it, that is - without porting the library?

I'm talking about c++ supporting libraries. Clearly if I need a c standard library, which requires certain syscalls, then I have to port a c standard library. But what about other C++ supporting libraries? Can I just statically link to them with my c standard library and will it just work?

As for crt0, my kernel startup is pretty particular, I don't want newlib providing the entry symbol, yet all the guides show that way of doing things. I'm wondering if I am going about things the wrong way in this case?