Le 08/10/2009 19:02, David Brownell a écrit : > 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". > > It is easier just to create 2 different compilers, one with libc and one with newlib
> 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. Not always true, with the software I got from Atmel for the AVR32 U3 devices they have FAT a library > 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. > > - Dave > They do in newlib but that is bloated stuff which I never use. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development