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