The openrisc bugtracker has been moved to: bugzilla.opencores.org. This page is read-only
not always linking free() for newlib
Information:
Type :: REQUEST
Status :: CLOSED
Assigned to ::
Jeremy, Bennett
Description:
In gcc-4.2.2/gcc/config/or32/or32.h, there's "-u free" option for always linking free() and malloc() with newlib. We can save 3.8KB program and 2.1KB data memory if the application does not need free() and malloc().
text data bss dec hex filename (without "-u free")
1016 20 0 1036 40c cbasic-nocache-O0-wo-free.or32
text data bss dec hex filename (with "-u free")
4866 2128 56 7050 1b8a cbasic-nocache-O0-free.or32
-Yishin
Here's the patch:
Index: gcc-4.2.2/gcc/config/or32/or32.h
===================================================================
--- gcc-4.2.2/gcc/config/or32/or32.h (revision 259)
+++ gcc-4.2.2/gcc/config/or32/or32.h (working copy)
@@ -63,10 +63,10 @@
version of the library, but it does have a debugging version (libg.a) */
#undef LIB_SPEC
#define LIB_SPEC "%{!mor32-newlib*:%{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}} \
- %{mor32-newlib:%{!g:-lc -lor32 -u free -lc} \
- %{g:-lg -lor32 -u free -lg}} \
- %{mor32-newlib-uart:%{!g:-lc -lor32uart -u free -lc} \
- %{g:-lg -lor32uart -u free -lg}}"
+ %{mor32-newlib:%{!g:-lc -lor32 -lc} \
+ %{g:-lg -lor32 -lg}} \
+ %{mor32-newlib-uart:%{!g:-lc -lor32uart -lc} \
+ %{g:-lg -lor32uart -lg}}"
/* Old definition of LIB_SPEC, not longer used. */
/* Which library to get. The only difference from the default is to get
Comments:
| Bennett, Jeremy | Sep 6, 2010 |
|---|---|
|
Request 1838 for an option to disable malloc/free linking replaces this. Marking closed. Jeremy |
|
| Bennett, Jeremy | Sep 1, 2010 |
|---|---|
|
Hi Yishin, It's a nice idea, but it doesn't work when you need malloc () and free () indirectly. I originally used your solution, then had to change it to add "-u free". The problem is that malloc () and free () are both declared as weak references in newlib. Your solution is fine if I call them directly from my program. However if I use a library routine, that in turn requires malloc () and free (), it will not search for them in the library. That's how weak references work (you get the same for example in the ARM libraries). I don't understand why malloc () and free () are done this way in newlib 1.18.0. I'm open to better suggestions. One possibility would be yet another option -mno-malloc, to eliminate the linking of free () and malloc (). I'm not sure how big a problem it really is. So many of the library routines actually use free () and malloc () that it is hard to think of many programs that could avoid linking them. The only ones that might probably ought to be running without a library at all. Jeremy
-- |
|
Post a comment:
Login to post comments!