I moved the exit handler from exit.c to retarget.cpp where the rest of
the standard C library retargetting routines are found. The exported
makefiles already explicitly link in retarget.o but not exit.o
When building with the GNU toolchain, it is safest to link in the
object file directly for retargetting routines so that GNU linker has
to use these versions of the routines.
Testing:
I have only tested this change with GCC_ARM. It should really be
tested with more toolchains before getting merged.
A recent commit, 43acaa4166, to get _sbrk() to build successfully for
LPC2368 broke the Cortex-M implementation. __get_MSP() isn't ever
defined as a macro, it is an inline function. This means that the
code would always be compiled to use SP instead of MSP on Cortex-M
parts. I switched the code to instead use the TARGET_ARM7 define
to choose which stack pointer to utilize.
I tested this fix by making sure that the LPC2368 version of the mbed
SDK would still build successfully with the Python scripts and that the
NET1 test still built and ran successfully on my mbed-LPC1768 device.
If the FileBase::lookup operation in the constructor of FilePath returns
NULL, subsequent operations (such as isFile()/isFileSystem()) will call
methods on a NULL 'fb' pointer. This commit fixes this issue by adding
explicit NULL checks and a new method in FilePath (exists()).
I verified that the hang issue I was seeing when building and running
the mbed official networking tests with GCC_ARM was related to this
issue reported on the mbed forums:
http://mbed.org/forum/mbed/topic/3803/?page=1#comment-18934
If you are using the 4.7 2013q1 update of GCC_ARM or newer then it
will have a _sbrk() implementation which checks the new top of heap
pointer against the current thread SP, stack pointer.
See this GCC_ARM related thread for more information:
https://answers.launchpad.net/gcc-arm-embedded/+question/218972
When using RTX RTOS threads, the thread's stack pointer can easily
point to an address which is below the current top of heap so this
check will incorrectly fail the allocation.
I have added a _sbrk() implementation to the mbed SDK which checks the
heap pointer against the MSP instead of the current thread SP. I have
only enabled this for TOOLCHAIN_GCC_ARM as this is the only GCC based
toolchain that I am sure requires this.
- rename stdio.cpp to retarget.cpp, since it doesn't contain only stdio-related
code
- move __cxa_pure_virtual from exit.c to retarget.cpp where it belongs.
sg-
Masao Hamanaka
0xc0170
Adam Green
GustavWi
Martin Kojtal
Alexander Valitov
Andreas Løve Selvik
Bogdan Marinescu
dinau
Bogdan Marinescu
Emilio Monti