Compile newlib with -DMALLOC_PROVIDED #81
Conversation
ESP provides its own malloc, so whenever newlib tries to use its own implementation, bad things happen. This way, *alloc symbols remain external in libc.a and can be redirected to the ESP versions. Right now this is left to the user.
|
Which library of which SDK version defines malloc? |
|
as it is, none. to make use of any functions from newlib that use malloc, user has to define his own shims (as we do in our code). but i did not want to complicate this PR further. what i'm doing here is the first essential step to make proper memory management possible at all (with shims). |
|
in our code we define |
|
So, I guess that's the case when whole solution should be presented, one step looks pretty random. It's otherwise known that newlib config for esp8266 needs tweaking: jcmvbkbc/crosstool-NG#2 . And good way to do it would be doing it upstream, instead of patching it here (though if there're reasons it can't be done upstream, then sure). |
|
what do you mean by upstream? espressif can't fix it in their SDK, crosstool-ng is built outside it. |
|
By upstream I mean project whose ticket linked above - https://github.com/jcmvbkbc/crosstool-NG , which is crosstool-NG with Xtensa support maintained by @jcmvbkbc. I just use it, mostly as-is. So, please discuss this matter with him and see what he says. |
|
and that is not the matter for them either. it may be perfectly ok to use newlib in reentrant mode with its own allocator in other projects with xtensa chips. it's just that ESP clearly has their own allocator and thus this is what newlib should be using. |
|
in fact, it might've been better to use newlib and its allocator, but given the situation with ESP where we have an allocator burned into rom and rom functions using it, we have no choice: there shall only be one system allocator, and in our case it has to be the one in ROM. this may not necessarily be the case for other users of xtensa chips. |
Update esptool commit
|
@jcmvbkbc can you give your opinion here? i think the default for crosstool should be kept as is and here , in ESP integration, we should change that to existing malloc. |
Move other lib patching to the Makefile
Compile newlib with -ffunction_sections and -Os
SDK 1.5.0 and GDB 7.5.1 patches from Sysprogs
SDK 1.5.2
|
Better late than never? |
|
indeed! thank you! :) |
In other words, %ll, %f and %z.
Enable long long, float and C99 formats in Newlib
Update to new Crosstool-NG, SDK 2.0.0, -mforce-l32
Update to latest available SDK
ESP provides its own malloc, so whenever newlib tries to use its own implementation, bad things happen.
This way, malloc symbols remain external in libc.a and can be redirected to the ESP versions.
Right now this is left to the user, though an argument can be made for including them.
This change should not break any existing users because newlib's functions that use memory allocation would not work correctly anyway. This change makes use of those functions possible with appropriate malloc function definitions (trivial shims to the pvPort* variants).