[Newlib] Problem with malloc() and free()

[fiveayem]

Hello,

Now I have ported Newlib for my OS and I can compile very simple programs, but I realized that there is a problem with the support of standard functions such as malloc() and free(). Indeed, when I try to compile a program using those functions with my OS-specific toolchain, I get the following error from GCC :

incompatible implicit declaration of built-in function malloc() (same for free()).

However, I do include stdlib.h.

How do you account for this error ?

Thanks for your help.

[bluemoon]

As the error message suggested, you have an incompatible implicit declaration of built-in function malloc()

Show us your malloc() function, make sure it is void*malloc(size_t size);


EDIT: if you are calling newlib's malloc there should be no such issue at all, by reverse logic I conclude the newlib is not successfully ported.

[brain]

did you accidentally forget the flag -no-builtins from your gcc command line?

[fiveayem]

I did not write my malloc(), I intend to use that of Newlib. I did not use -no-bultins flag. If Newlib was not successfully ported, what could be wrong (I followed the OS Specific Toolchain tutorial with gcc 4.4.3, binutils 2.20.1 and newlib 1.15) ?

[bluemoon]

As stated on the article,

Disclaimer
This tutorial is provided for people who are already happy compiling a GCC Cross-Compiler and are generally sure of what they are doing. It is not, in any way, inteded to replace the already excellent articles on GCC Cross-Compiler and Porting Newlib but is instead intended as a further resource for those who wish to take another step towards having their os become self-hosting. The other tutorials mentioned are extensively tested and known to work, whereas the steps described here (given their increased complexity) are expected to be less well tested and could well include a number of bugs.

Have you tried the GCC_Cross-Compiler and Porting_Newlib? It works "out of the box" for me.

[fiveayem]

Yes, I helped with the GCC Cross Compiler tutorial to compile GCC and binutils for my OS. And I also read Porting Newlib tutorial, but it seems that it does not bring much more information than OS Specific Toolchain.

I could write several programs with Newlib, all of them work fine, except when using malloc() or free(). Indeed, now I removed the warning by using --no-builtins flag, but calling malloc() always causes problems :

• If I call it at the very beginning of main() (or after some printf()), it always returns NULL.
• But when I do a scanf() before a malloc(), I just get a page fault !

So in fact, the problem is not totally solved...

[bluemoon]

As for the historical record, did you zero'ed bss? 99% of people are too excited to try newlib right after elf parser and they forget to zero bss

Anyway, follow exactly how the wiki say to build the tools and lib, there should be no warning about incompatible implicit declaration, there must be hidden problem on your built versions.

[fiveayem]

Yes, I have read about bss that it should be filled with zeroes. But how can I know where bss is located ?

EDIT : I do not know if it has anything to do with it, but when the p_filesz specified in a program header is less than the p_memsz, I do set the remaining bytes to 0.

[bluemoon]

I do it this way, someone here probably has more elegant solution.

The link script contain:

Code: Select all

.bss ALIGN(4096) : {
  sbss = .;
  *(COMMON*)
  *(.bss*)
  *(.gnu.linkonce.b*)
  ebss = .;
}

In the kernel entry code, i do this before enable paging and stuff:

Code: Select all

    mov     edi, sbss   ; my kernel is located at 3G, so edi -> 3G+bss offset
    mov     ecx, ebss
    sub     ecx, edi
    sub     edi, KERNEL_ADDR - KERNEL_PHYADDR  ; edi -> physical address (3G + bss offset - (3G - 1M)) = 1M + bss offset
    xor     eax, eax
    shr     ecx, 2
    rep stosd

You may also do that on the boot loader, look up the symbols and do the zero, it's up to you.

[fiveayem]

Well, as far as I am concerned, filling BSS with null bytes did not change anything (in fact, it was already done by my loader even though I did not realise, see previous message for more details). Maybe Newlib was badly ported. Indeed, the tutorial OS Specific Toolchain seemed a bit hard to me (I am not an expert about the insides of GCC and binutils), and moreover, the author said that the procedure he showed was likely not to work, while the method described in Porting Newlib had been largely tested and approved. So, I am giving up with my OS specific toolchain and I am going to try to build the Newlib once again, following this tutorial carefully.

[fiveayem]

Now I use my own malloc() and free(), and it works.