On Thu, Oct 8, 2009 at 7:02 PM, David Brownell <davi...@pacbell.net> wrote: > On Thursday 08 October 2009, Michel Catudal wrote: >> An arm-linux-gcc is only for Linux based system, not bare metal stuff. > > Depends what you mean by "bare metal". > > I use "arm-none-linux-gnueabi-gcc" all the time to compile > Linux kernels; and sometimes for U-Boot, or stuff running > on Cortex-M3. By any reasonable definition all of that > counts as "bare metal".
I'm building Contiki on the MC1322x. Contiki has things like exit() and snprintf() in it. Use the ARM9 compiler in OpenEmbedded those routines link to glibc and it brings in 900KB of code. So I have a working compiler, I just don't have a reasonable libc. > > So far as I can tell, all those compilers will work fine > in that mode: tell it to ignore all system libraries, not > to use dynamic linking, and get friendly with linker config > scripts ... and there will be no problem sticking the reset > vectors <here>, code <there> in NOR flash (or SRAM), etc. > You'd have to work hard to get that to break, as I understand > things. > > Now, the *libc* stuff is a more confusing story. Bare > metal has no file system, so fopen() raises conceptual > problems. Doesn't even have stdout, so printf() has > the same kind of problems. No network stack; socket() > is not gonna work either. But stuff like strcpy() can > work, vsnprintf(), and given some help you can even have > malloc() and free(). That's all system library stuff > though. libc is the problem. > > - Dave > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Jon Smirl jonsm...@gmail.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
