What functions to define for ARM newlib w/o "monitor" support?
Toralf Lund
toralf@procaptura.com
Fri Mar 12 12:19:00 GMT 2004
I've built an arm-coff compiler where I've tried to disable newlib's
lowlevel I/O routines, since these assume debug monitors my system
doesn't have. Now, when I link my app with these, I get
/usr/src/redhat/BUILD/cross-gcc-arm-coff-2.95.3/build-newlib/arm-coff/be/newlib/libc/reent/../../../../../../newlib-1.11.0/newlib/libc/reent/sbrkr.c:60:
undefined reference to `_sbrk'
/usr/src/redhat/BUILD/cross-gcc-arm-coff-2.95.3/build-newlib/arm-coff/be/newlib/libc/reent/../../../../../../newlib-1.11.0/newlib/libc/reent/readr.c:58:
undefined reference to `_read'
etc. This is sort of what I expect since I obviously need to write my
own sbrk, read, write etc. However, it seems like that in order to
resolve the references, I have to define _sbrk(), _read(), _write()
etc., while earlier when I did the same thing for m68k, those functions
were called sbrk(), read(), write() and so on, i.e. the function names
had no initial '_'.
Why this difference? Is this something I should expect, or does it mean
that I've disabled the wrong code section in newlib?
BTW, as I mentioned once several months ago: The arm build uses special
defines/-D flags to control its debug monitor setup; two different
monitors are supported, and the setup has an "enable" macro for each of
these. However, some sections of the code will enable one of the
monitors even if neither is defined. Isn't that somewhat inconsistent?
I'd say that as long as there are separate flags for the monitors, the
code should be built with support for none of them if no flag is set.
Alternatively, you could have just one flag and *always* assume the
"other" monitors when it's not defined.
--
- Toralf
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list