Newlib problem

[kubeos]

Hey guys. After taking the summer off of any type of coding... I'm picking up Kube (32-bit version) again.
Anyway, I'm trying to get newlib ported and am having a problem with printf.

If I use printf() in a test program and run it under my OS, it doesn't work unless I used exit() at the end of my main routine.
eg.

Code: Select all

int main()
{
      printf("hello world");
      printf("blah blah blah");
      exit(0);       <----------------- printf won't work without this.  WHY? :(
}

I setup some debugging output in my syscalls to see what is being called. No system calls regarding printf are send out unless the exit(0) is called. It seems like printf is being buffered until exit is called. I am not doing any buffering in my code that's for sure. I've checked my print and write routines in libnosys and they work fine. If I use print("blah") instead of printf everything works as it should. Has anyone had this problem, or have any idea of what I may be overlooking?

[edit] ALRIGHT, if i fflush(stdout) after printf then it works, also a '\n' works. Duh.. I never knew this was standard operation... or is it?

[xyzzy]

Yes, it's standard behaviour.

The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed.
This can produce unexpected results, especially with debugging output. The buffering mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call.

[kubeos]

Hey Alex,

I wanted to ask someone this for awhile. After you ported newlib, how hard was it to get the toolchain ported to your OS? I'm still working out a few bugs with my kernel to get newlib working right, but after it's done I want to move on to getting a real shell and binutils ported.

[xyzzy]

It didn't need much work. Just had to implement missing system calls (some I could just replace with stubs that set errno to ENOSYS).

[pcmattman]

I also pulled off porting binutils (not gcc yet, though it's ready to be compiled and have missing references fixed).

One of the advantages to porting something like binutils is that it really shows you all the bugs and problems in your system. It took me more time to fix the memory leaks and frustrating bugs like that after porting (and testing) binutils than it did to port the thing. But there's nothing quite like running ld under your own system on a binary compiled by NASM (run, of course, under your own system), and having it put a binary that your OS can run on the HDD.