libc port

[omin0us]

I have read the newlib is an easy to port libc. but all the documents provided on porting it aren't very good.

Has anyone here ACTUALLY ported it. and could provide a little help?
and if not newlib. could you suggest another libc that is easy to port and is complete enough to make it easy to run various gnu software

[Nick]

It's fairly straightforward. I simply compiled newlib with a cross compiler and linked it against my user mode programs.

You'll need to provide wrappers for the functions newlib expects to call (open, read, write, fork, etc.) so depending on how Unix-like your OS is this may or may not be easy. There's examples of do-nothing stubs near the end of the newlib documentation.

I also found I needed to fiddle with configure.host to stop some library routines (longjmp, ...) using privileged instructions (cli, sti). I guess this is because it's targeted at embedded systems. Most of it worked out of the box anyway.

[omin0us]

so wait...i need a cross compiler for my kernel?
why do i need a cross compiler for newlib if my kernel is x86 based?

[Nick]

A cross compiler isn't technically required but it certainly makes things easier and ensures you don't accidentally pull anything in from the host OS.

Also, since newlib is primarily for embedded systems it's dead easy to build if you have a cross compiler. E.g. if you've built an i586-elf toolchain you can run the newlib configure script with --target=i586-elf and the build process will use your custom toolchain.

At least this is how I did it. Using your native compiler might work just fine as well.

[omin0us]

ok, i'm creating an i586 cross compiler right now.

if i build newlib using configure --target=i586-elf
how does it know to use my stubs?

[spix]

if i build newlib using configure --target=i586-elf
how does it know to use my stubs?

Good question.

Newlib determins what stubs to use in the configure.host file in the newlib directory.

You use sys_dir=yoursys

I guess you could make/modify an entry for i586-elf. It's easier to create your own target.

The way I did it was to hack gcc and binutils configure scripts to include my own target i486-pc-mort by copying the entries for i586-elf. You can also configure in binutils to have ld link your executables in the right location so you don't need a linker script when compiling ordinary applications.

Andrew

[omin0us]

thanks a lot for the help. i got it figured out today.

[omin0us]

I ran into a problem. I got it to build and provided some of the basic syscall stubs (particularly the ones need for printf -- open, close, read, write, lseek, fstat, isatty, sbrk i think).
And the internal malloc seems to be broken? i keep getting a page fault when anything calls it. Has anyone else had this problem with newlib?
i check the faulting EIP and it is within _malloc_r.

Any help please?

[spix]

And the internal malloc seems to be broken? i keep getting a page fault when anything calls it. Has anyone else had this problem with newlib?

malloc in newlib is fine.

i check the faulting EIP and it is within _malloc_r.

I have had this happen before but I don't remember what the cause was, except that it was something in my kernel.

You probably want to check obvious things like sbrk, page mapping/permission and that your program isn't broken. But these sort of problems can often be caused by a bug much more obscure in your code, and seemingly unrelated.

Sorry I can't be more help. A debugging version of bochs is your friend, and a big pot of coffee.

Good Luck
Andrew