Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »
July 17th, 2017 by Colin Walls
For a software developer, the idea of a library is quite simple: It is a file containing a (typically large) number of functions/procedures/subroutines in a special format. At link time, the linker looks in the library (or there may well be more than one, in which case it checks each in turn) to resolve any references to functions not satisfied by the supplied object modules. This means that the programmer just needs to reference commonly used functions and their code is pulled in automatically.
Of course, it is not quite that simple. Also, as with most aspects of embedded programming, libraries present more challenges and options to developers …
When developing software for the desktop, most programmers give little consideration to standard libraries, concentrating only on any special libraries that might be employed for their application. Such libraries are commonly dynamically linked, so they are quite different from anything used in most embedded systems.
The fact that every embedded system is different is often cited (by me anyway) as a reason for much of the complexity with developing embedded software. The use of libraries reflects this. Apart from getting a library that is right for the target device family and the chosen compiler, there may be a wide selection of other variations: chip family member specifics, register relative addressing, PC relative (position independent) code, endianity, size/speed optimization, the list goes on …
A standard C library contains two types of functions:
Commonly a single library is used to contain both these types of function. However, that is not always the case. For GNU compilers, one library (libgcc) contains the compiler support functions. There are a number of options to choose from for the explicitly called functions:
An interesting question is: what is the benefit of a smaller library, given that only called functions are extracted from it so final binary image size will not vary? I can think of about three answers:
One Response to “C libraries”