fwrite

[omin0us]

Ok, so i'm having a bit of a problem with fwrite inside newlib

Back story:
I have ported newlib and it has been working fine all the small apps i've written to run on my kernel. But then i finally ported nasm, and binutils to my OS, When I run gnu as or nasm to assembly some code on my OS, the object file is created on the file system, but nothing is written to it. They are using fwrite to do this, and the data should be getted written when the buffers are flushed, so stepping through fflush, i can see the data in the buffers (i spotted the elf header it was trying to write, as well as the section names, .bss, .text., etc). But the way it calculates how much it needs to write is with this line (from fflush.c of newlib)

Code: Select all

n = fp->_p - p;       /* write this much */

one of those pointers should be pointing to the end of the buffer, and the other should be pointing to the beginning, so that the subtraction gives us how many bytes to write into n. but for some reason they are both pointing to the beginning of the buffer. =/ so n == 0, and then it writes nothing.

So my question is, wtf... shouldn't i just have to provide a properly working open, read, write, seek, and close for fwrite, fopen, etc to work properly? I cant think of what I've down wrong, as my open, read, write, etc all work perfect, I've tested them with many many applications.

I could fix this by rewriting a bit of the newlib fflush/fwrite code, but i would assume i shouldn't have to do that for it to work if its relying on my system calls. i'm kind of at a loss. I've tried stepping through newlib as its executing, but for some reason gdb seems to just jump randomly around the source file. not sure why.

Sorry for the long post. I would appreciate any help i can get on this. thanks :]

[Solar]

GDB jumps around sources: Everything compiled with debug symbols and frame pointers enabled? Source file and binary file versions identical?

For debugging, does output to screen (printf) work? If yes, hack some output in the relevant functions (fwrite(), the write() stub, fflush, ...) to print the values of those two pointers to screen. You already know they're borked when it comes to flushing, now you have to find out where they aren't set as they should.

[Combuster]

Apparently this was crossposted to alt.os.developmentand answered there...

[omin0us]

yes, thanks guys. apparently 2 very important lines got removed long long ago that i was unaware of. I figured this out by diffing my copy with a fresh downloaded copy. Nasm and GNU as are both able to produce elf object files now. :] I am very close to my first 0.1 release of my OS now