David S. wrote:

>[...]
> - newlib. I suppose these are libraries like standard's C libraries?
Yes, newlib is a libc (and libm). Basicly like the glibc you know from
your Linux-Box. There are others like dietlibc und uclibc but AKAIK
newlib is mostly used for "bare metal" developments because the license
is not as restrictive as for the other open-source libcs and the memory
"footprint" is relativly small.

> WinARM and YAGARTO are compiled to used the functions implemented in the
> library newlib.
WinARM, Yagarto, GNUARM, devkitpro, Idealist and many other
precompiled/packaged GNU toolsets include libc/libm (several b/o
multilib) based on newlib sources. Rowley has developed it's own libc
and the very (very) old package from Keil uses the uclibc (I they have
not updated in the meantime).

> newlibLPC is just low level calls for hardware
> specific¡s. But I've got many uncertainties and mixed concepts... I
> visited their website but is a bit confused to me...
Think about sending the output of printf to an UART. newlib itself does
not know how to write a character to an UART or the location of the heap
for temorary storage. It can format the string for output but finaly it
needs some memory for the heap and a function to send the character to a
"file". This interface functions is are "syscall" (sbrk and write in
this case). Basicly newlibLPC implements the syscalls for (some) NXP
LPC2000 controllers (it offers more, but this is the most important
feature). See the libc manual of newlib for further information on
syscalls. You can also read the source of newlibcLPC and also Dave
Murphy's devkitpro/libsysbase for syscall implementation details which
offer fileid support. Some of my WinARM examples include some very
simple syscall implementations.

> - I already studied makefiles and load script files, and managed to get
> a clear idea of how to use them. I just need some practice. But, for
> example, where does .glue_7 section come from??
This question came up a few days ago. glue-functions are generated by
the compiler to interface between binary code in ARM and thumb mode
(basicly just a wrapper for the BX assembler-instruction). If you have
built some interwork code look at the disassembly (created with
arm-*-objdump) and you should quickly see what's going on.

> I'm familiarized with
> .text, .data and .bss sections, as well as .rodata. But I wonder where
> are all these sections defined... I know how to allocate code to them,
> but where is it defined that .text section is for executable code? or is
> it just an arbitrary name ??
Hmm, never thought about this and just used it. I guess .text is
internaly defined with the "ax" bits. You may read the documentation on
sections in the GNU assembler manual. Distinguish .text as a section
used by the compiler for code and .text as used as linker-section. Just
reading the some linker-scripts should get you the idea (i.e. the
default linker script, output from arm-*-ld --verbose)

> what about glue_7 or glue_7t??
see above

> - I also don't get a clear idea of what does it mean, that WinARM is
> compiled with newlib reentrant functions and system call disabled, while
> YAGARTO is compiled in default mode...
Well, I have build newlib for the first version of WinARM like this
since the newlibLPC depended on this kind of configuration. I have not
changed it since, to keep compatiblity. AFAIK YAGARTO does not support
newlibLPC "out of the box". The default newlib-build includes
implementations for syscalls. AFAIK they route the syscalls to SWI calls
which can be catched by a debugger prepared for "semihosting" (and the
gdb armulator). Semihosting is examplaind in several documents available
from arm.com. You could also create you own SWI-handler to process
"semihosting syscalls".

> I mean, for me, a system call is
> something a process calls, that is managed and provided by the OS. But
> what if you've got no OS ??
Well you somehow have to provide a "primitive OS" which implements the
systemcalls (like newlibLPC does or a Semihosting "host" does. It can be
roughly compared with implementing a BIOS for a PC to run "DOS
software".

> Let me say that I DO know what reentrant function is ! I think I've got
> plenty of basic knowledge to understand these topics, but never heard or
> had the chance of studing it in depth. So I'm not asking for basic
> computer / software theory explanation, but a guide for getting to know
> all this wonderfull world of GNU, toolchains, libraries,... stuff, from
> the ground up, and not just use it at a user level.
Well, "user level" is a little difficult to define for "bare metal"
development. If you do not use ready-made code like an OS with BSP or
libraries esp. created for one controller like newlibLPC you often have
to do a lot of "groud up" coding.

> I don't mind reading any avaiable source of information, just need some
> help getting on, and some basic directions, as my job doesn't let me lot
> of free time...

I hope my reply helps at least a little bit. I have to admit that I'm
not a full-time professional microcontroller developer and also still do
not understand all gcc/binutils/newlib internels. But there are other
readers of this forum who know more than I do and may help. You can also
ask in the gcc-, newlib-, binutils-mailing-lists, the GNUARM yahoo group
and the Sparkfun ARM-forum just to name a few.

Martin Thomas

Thank you, yes, it's been very usefull.

About the sections question. I'm mainly concerned about this, because
when writtin a linker script, you must know all sections that exist, so
you can allocate them. .text, .data. bss. .rodata, .glue_7 and .glue_7t
is what I know. And of course, all sections defined in the source files.
Are there anymore?

Also, looking at the WinARM directory, I find 3 subdirectories in
different paths, that are named 'include' and hold header files. Which
one is the newlib's include dir ?? and the other two ??

Yes, user-level in this are, is someone who just codes in C, but is not
able to write makefiles, load scripts, recompile libraries, undertand
deeply how libraries are linked, etc... Well, to be sincere, I don't
even know what glibc is, so I have quite a lot to learn...

Ok, I see in the makefiles that the sources are linked against libc and
libm, but I see no reference to newlib. Perhaps newlib = libc + libm ??
I still don't know which of the three "include" folders inside WinARM
holds each library headers. There's one inside arm-elf folder, another
one in the root, ... could you tell me please?

David S. wrote:
> Ok, I see in the makefiles that the sources are linked against libc and
> libm, but I see no reference to newlib. Perhaps newlib = libc + libm ??
Yes

> I still don't know which of the three "include" folders inside WinARM
> holds each library headers.
In WinARM: arm-elf/include (or arm-eabi/include for the latest
test-version). This should be the same for all other precompiled GNU
packages (if the packager did use standard configuration).

> There's one inside arm-elf folder, another
> one in the root, ... could you tell me please?
The one in "root" is for Win32 TCL/TK used by Insight AFIAK. Not part of
the bintuils/gcc/newlib. lib/gcc/arm-*/<version>/include are
include-files from the compiler installation (see README in this
directory)

This might help:
http://www.quantum-leaps.com/resources/papers.htm##GNU-ARM

Newlib is a lightweight Standard C library. Unlike the GNU C library it
does not assume or require a Linux or Unix like environment, making it
suitable for embedded systems. Also unlike GNU libc/libm if is not LGPL
licensed.

The Newlib library is built using the same archive names (libc.a and
libm.a) because that is what the GNU compiler expects when it links the
default libraries.

The Syscalls stubs allow you to hook Newlib into your particular
platform and environment as you see fit. You can make them elaborate so
that file systems and buffered, interrupt driven I/O are supported for
example, or minimalist so that the code links and runs but may restrict
some functionality.

Generally as a bare minimum you should implement sbrk at least so that
dynamic memory allocation works correctly, since some parts of the
standard library require it. C++ is somewhat crippled without an sbrk
implementation since the 'new' operator will not work, much less the C++
library.

Clifford

Thanks to both of you, it's a bit more clear now.