Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
Offline GCC compiler works with mbed libraries!
Achmad Fathoni.
215
replies
Adam Green wrote:
Thierry, just try rerunning the existing script. Don't attempt to use Dan's Mercurial suggestion. That won't be compatible with the current master branch of the gcc4mbed project.
May I need to start from the beginning, downloading the first file?
B Thomas wrote:
I get the following error "multiple definition of `aeabi_unwind_cpp_pr0'". I would be grateful for any help here (complete log is given below). Does aeabi_unwind_cpp_pr0 need to be redefined in gcc4mbed.c ?
I hit this issue earlier in the week when building a program which used iostream functionality from the C++ standard library. I have removed the aeabi_unwind_cpp_pr*() functions from gcc4mbed.c and see that it no longer results in larger binary size when using the newlib nano library. The GCC4MBED project on github now contains the fix for this issue.
Adam Green wrote:
I will investigate another solution next week as well. I have the newlib nano code building on my MacBook Air. I will try to add support for 64-bit ints to it without blowing the code size up too much. That would probably be the best solution.
-Adam
Adam,
I like this proposed solution the best apart from the extra work that it requires from you. I really do like the smaller object sizes.
I think that 64bit (signed/unsigned) integer printf/scanf is a different requirement to 64bit float/double printf/scanf. I do not know of any cases where I would be using 64bit floating point string io.
If you do add the 64bit int support, is it worth having defines in the style of NO_FLOAT_SCANF/NO_FLOAT_PRINTF for 64bit integer support (NO_LL_SCANF/NO_LL_PRINTF).
Regards,
Jonathon
Adam Green wrote:
Hello Gustavo,
There are two things going on here.
- gcc4mbed now uses newlib-nano for the C standard library to produce smaller binaries. This version of newlib doesn't support the malloc_stats() call.
- You get the "multiple definition" error from the linker because of something that I did wrong in the gcc4mbed makefiles which allows a mix of newlib standard and newlib-nano to be linked in.
Unfortunately, even after I fix my makefile issue, you will still get an 'undefined reference' linker error since it won't be able to find any definitions of the required _malloc_stats_r() function once only newlib-nano is used. In the future I hope to port some of my heap tagging extensions into gcc4mbed. These allow dumping of the heap from within the GDB debugger. You can see used and free locations in the heap and even get the name of the caller who made each allocation. I have had this working in the past for newlib but I need to do some porting as newlib-nano uses a different (simpler) heap structure.
Hello Adam,
Thanks for your answer. I was trying to use this functions to analize the heap memory as you notice. Did you know any other way to do this with the current port?
Regards, Gustavo.
Wim van der Vegt wrote:
Any suggestions how to get past this point?
My guess is that you get this error when you try to compile a .c file. Previously such files were treated as C++. They are now treated as C source code. If you rename the offending file to have a .cpp extension then things might improve.
I hope that helps,
Adam
Gustavo Ojeda wrote:
Did you know any other way to do this with the current port?
This is on my list to look into. I will bump it up in priority and let you know what I discover.
Are you comfortable with using GDB, the GNU Debugger? I have an introduction on how to use GDB with GCC4MBED here. Any solution that I come up with to dump the heap statistics will probably be through the debugger.
If you are using the version of GCC installed by GCC4MBED's install scripts then you can use the following command in GDB to dump the amount of memory currently dedicated to the heap:
printf "heap size=%d\n",**(int**)(_sbrk+28) - ((((int)&Image$$RW_IRAM1$$ZI$$Limit)+7)&~7)
Sorry that it is so ugly. It turns out that there are no symbols for the _sbrk() implementation used by the current GCC4MBED so I have to reach into the _sbrk() machine code to pull out the pointers I want from its literal pool. If you installed a different version of GCC yourself and added it to your PATH then the above trick will not work since the code output will be slightly different.
There can be free chunks within this heap but printed values of heap size will tell you the maximum amount of heap that was required or if it is growing over multiple samples. I don't believe that the heap implementation in newlib-nano will ever decrease this value (the standard newlib implementation would.) So even if you free up everything, you will still see the maximum heap size ever required printed by the above command. However, the heap will be tracking free space with this heap and new allocations will be satisfied from it first before it grows the heap any more.
If you don't mind growing the size of your program, you could also switch back to using the standard newlib library instead. This would allow malloc_stats() to work. You could edit build/gcc4mbed.mk to change this line:
SYS_LIBS = -lstdc++_s -lsupc++_s -lm -lgcc -lc_s -lgcc -lc_s -lnosys
to
SYS_LIBS = -lstdc++ -lsupc++ -lm -lgcc -lc -lgcc -lc -lnosys
I hope that helps,
Adam
Do you get a prompt for a Authentication Realm password at this time?
No, I did not get it.