ESSENTIAL For EMBEDDED Developers

The open source way! An overview of Linux environment Linux Evolution What is Linux? Distributions Linux Linux Everywhere The archives http://en.wikipedia.org/wiki/Linux GNU/Linux

• Recursive acronym “GNU’s not UNIX” • http://www.gnu.org/ not http://www.gnu.com/ • Richard Stallman (1983) Goal a free Unix • Known for Free Software movement, GNU, Emacs, gcc • Never really released GNU • Linus 1992 open sourced Linux Kernel and named GNU/Linux

• Free Software Foundation • http://www.fsf.org/

http://en.wikipedia.org/wiki/GNU Typical Linux SYSTEM Layout

System Reserved

Rootfs

Kernel

Bootloader

Hardware Linux Distributions

•Redhat/fedora/Centos • Most popular, good all around choice • Fedora – community supported • Enterprise Redhat – corporate supported •Debian/Ubuntu/Mint • Completely noncommercial • Massive package selection and easy management • Not as user friendly, but improving •SuSe • IBM Preferred Linux – z/Series Linux of choice Embedded LINUX The Blackfin uClinux Distribution by Analog Devices – a fork of the uClinux distribution for Blackfin processors

Embedded Alley - see http://www.embeddedalley.com/

Lineo Solutions uLinux

MontaVista Linux - see http://www.mvista.com/products_services.php

Pengutronix - see http://www.pengutronix.de/oselas/bsp/index_en.html

RidgeRun Linux - see http://www.ridgerun.com/sdk.shtml

TimeSys Linux- see http://www.timesys.com/embedded-linux/linuxlink

Wind River - see http://www.windriver.com/products/linux/

Digi Embedded Linux for Digi's ARM based modules Virtualization

Guest Operating System Virtualization Shared Kernel Virtualization VMware Server and VirtualBox. Linux VServer, Solaris Zones and Containers, and OpenVZ

See CoLinux MkLinux Kernel Level Virtualization Virtualization (UML) and (KVM). , VMware ESX Server and Microsoft's Hyper- technology Linux KERNEL TODAY Kernel.org Linux Kernel Information

l The Linux kernel version numbers consist of three numbers separated by decimals, such as 2.2.14. The first number is the major version number. The second number is the minor revision number. The third number is the patch level version l There are two stages of kernel releases: “stable” and “development”. Development kernels end in an odd number (2.3, 2.5, …), stable or production kernels end in an even number (2.4, 2.6,3.0). l Once a kernel is deemed stable, it will move from an odd to even second number for release (e.g., from 2.3.51 to 2.4.0). l You can get a good sense of what the future production state of Linux will be by looking at the development kernel. l http://www.kernel.org Application interactions in Linux The Kernel Architecture overview and address space view Application and modes of operations, Kernel and User address Spaces System call, entry and exit points, low level view, strace, parameter passing and kernel implementations Structure: The “Core” Linux Kernel

Applications

System Libraries (libc)

System Call Interface

I/O Related Related File Systems Scheduler Networking Memory Management Modules Device Drivers IPC

Architecture-Dependent Code

Hardware Operative Modes

• To avoid having applications that constantly crashed, newer OSs were designed with 2 different operative modes:

• Kernel Mode: • the machine operates with critical data structure, direct hardware (IN/OUT or memory mapped), direct memory, IRQ, DMA, and so on.

• User Mode: • users can run applications. User mode & Kernel mode (32 bit)

0xFFFFFFFF

Kernel Address Space 1G

0xC1000000 0xBFFFFFFF | Mdm | Mdm | User Address Space 3G gnome-terminal | Bash | App.exe

0x00000000 Operative Modes

• Kernel Mode "prevents" User Mode applications from damaging the system or its features.

• Modern microprocessors implement in hardware at least 2 different states. For ex. under Intel, 4 states determine the PL (Privilege Level). It is possible to use 0,1,2,3 states, with 0 used in Kernel Mode.

• Linux/Unix OS requires only 2 privilege levels, and we will use such a paradigm as point of reference Switching from User Mode to Kernel Mode-1

• When do we switch? • Once we understand that there are 2 different modes, we have to know when we switch from one to the other.

• Typically, there are 2 points of switching:

1. When calling a System Call: 2. When an IRQ (or exception) comes Let’s observe the user/kernel space

• use vmstat to grasp recent process context call vs System Call in Linux Wrapper and Wrapper based System call , Entry and Exit Points Example of wrapper to a system call flow System calls

• The main interface between the kernel and userspace is the set of system calls • About ~300 system calls that provides the main kernel services • File and device operations, networking operations, inter- process communication, process management, memory mapping, timers, threads, synchronization primitives, etc. • This interface is stable over time: only new system calls can be added by the kernel developers • This system call interface is wrapped by the library, and userspace applications usually never make a system call directly but rather use the corresponding C library function System Calls: read

• C example: count = read(fd,buffer,nbyte)

• push parameters on stack read library procedure

register • call library code X (read) count = read (fd , buffer , nbytes)

memory (stack) application buffer • put system call number in register nbytes buffer fd • call kernel (TRAP) kernel space • kernel examines system call number • finds requested system call handler • system call execute requested operation handler

• return to library and clean up • increase instruction pointer X • remove parameters from stack sys_read() • resume process Kernel Entry and Exit

app app Library Code exceptions (error traps) System Call Interface trap

80h trap / system boot interrupt call scheduler table table Kernel device interrupt page faults dialog Devices System Calls vs. Library Calls

• man 2 • historical evolution of # of calls • Unix 6e (~50), Solaris 7 (~250) • Linux 2.0 (~160), Linux 2.2 ( ~190), Linux 2.4 (~220) • library calls vs. system call possibilities: • library call never invokes system call • library call sometimes invokes system call • library call always invokes system call • system call not available via library • can invoke system call “directly” via assembly code Cost of Crossing the “Kernel Barrier”

• More than a procedure call • Less than a context switch • Costs: • Establishing kernel stack • Validating parameters • Kernel mapped to user address space? Implementation Example: “Hello, world!”

.data # section declaration msg: .string "Hello, world!\n" # our dear string len = . - msg # length of our dear string

.text # section declaration

# we must export the entry point to the ELF linker or .global _start # loader. They conventionally recognize _start as their # entry point. Use ld -e foo to override the default. _start: # write our string to stdout

movl $len,%edx # third argument: message length movl $msg,%ecx # second argument: pointer to message to write movl $1,%ebx # first argument: file handle (stdout) movl $4,%eax # system call number (sys_write) int $0x80 # call kernel

# and exit

movl $0,%ebx # first argument: exit code movl $1,%eax # system call number (sys_exit) int $0x80 # call kernel Linux System Calls (1)

Invoked by executing int $0x80. • Programmed exception vector number 128. • CPU switches to kernel mode & executes a kernel function. • Calling process passes syscall number identifying system call in eax register (on Intel processors). • Syscall handler responsible for: • Saving registers on kernel mode stack. • Invoking syscall service routine. • Exiting by calling ret_from_sys_call(). Parameter Passing

• On the 32-bit Intel 80x86: • 6 registers are used to store syscall parameters. • eax (syscall number). • ebx, ecx, edx, esi, edi store parameters to syscall service routine, identified by syscall number. Interacting with Modules

App_1 App_2 App_N

/dev/device_nodes

Vmlinux module.ko Basic utility, filter & developer command essentials Understanding Root File System Hierarchy Linux File systems on desktop

• Historically Linux had no fs of its own and formally had fs running on it • Later adpoted the the second extended file system formally known as ext2fs • Has been enhanced to ext3fs, ext4fs • Now the Linux 3.X is looking to have • Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration Linux Tree Hierarchy

/

/root /bin /proc /usr /sbin /dev /opt /home

/src /home/ram

linux /home/sita

/ - (unnamed) the actual root /usr – usr utilities and application /sbin – special commands /privileged /root – a home area for root /dev – device node for external devices /bin – utility commands /opt – optional applications /home – usually all you do is here /proc – a bogus fs for Linux kernel /var – spool , log messages etc The Shell

• Command interpreter in original Unix • Read command • Perhaps pre-process command • Fork/execute • Return exit status of command • A little history revisited • Bourne Shell (sh) • C chell • Korn shell • Bourne Again shell (bash) Entry level commands

• man • date • which • cal • whatis • who • info • w • apropos • id • Write • mesg • bc PiPEs (|) & FILTER PROCESS • ps • grep • nice • sort • sleep • tr • at • cut • nohup • paste • kill • more • ctrl+c • less • ctrl+z • head • fg • tail • bg • nl • top • tee • vmstat • wc FILEs/misc DIR/FILE • chmod • pwd • chgrp • mkdir • Chown • cd • comm • Ls • cmp • rmdir • diff • cat • Uniq • cp • touch • ln • stat • mv • file • rm • compgen CSCOPE

• Look at the function definitions straightway from the function call • Look out for all the places from where a particular function is being called. • Searching strings and patterns • Determining sources which include a specific header • Besides, it does editor tasks like viewing the source file, replacing strings, etc CSCOPE

• $ cscope -help • Usage: cscope [-bcCdehklLqRTuUvV] [-f file] -L Do a single search with line-oriented output. [-F file] [-i file] [-I dir] [-s dir] -l Line-oriented interface. • [-p number] [-P path] [-[0-8] pattern] -num pattern Go to input field num (counting [source files] from 0) and find pattern. • -b Build the cross-reference only. -P path Prepend path to relative file names in • -C Ignore letter case when searching. pre-built cross-ref file. • -c Use only ASCII characters in the cross-ref -p n Display the last n file path components. file (don’t compress). • -d Do not update the cross-reference. -q Build an inverted index for quick symbol searching. • -e Suppress the -e command prompt between files. -R Recurse directories for files. • -F symfile Read symbol reference lines from -s dir Look in dir for additional source files. symfile. -T Use only the first eight characters to match • -f reffile Use reffile as cross-ref file name against C symbols. instead of cscope.out. -U Check file time stamps. • -h This help screen. • -I incdir Look in incdir for any #include files. -u Unconditionally build the cross-reference file. • -i namefile Browse through files listed in -v Be more verbose in line mode. namefile, instead of cscope.files -V Print the version number. • -k Kernel Mode – don’t use /usr/include for #include files. SHELL • Internal commands vs external commands • Variables- local, exported, ENV • Arithmetic- expr [ +, - ,\*, /, %] • Controls • if [ expression] ;then; … else … fi • case expression in ; 1) ;; 2) ;; *) ;; esac • Looping: • while [ expression ] do … done • until [ expression ] do … done • for index in expression do … done • Command Line • $1, … $9 • shift • $*, $#, $$, • Set • Funtion: • hides the command line • must assign to shell vars Building Applications on Linux

Tool Chain Overview and Component Binutils, Kernel-header, GCC, Library, Debugger, Vendor & Pre Built Definition

• The usual development tools available on a GNU/Linux workstation is a native toolchain • This toolchain runs on your workstation and generates code for your workstation, usually • For embedded system development, it is usually impossible or not interesting to use a native toolchain • The target is too restricted in terms of storage and/or memory • The target is very slow compared to your workstation • You may not want to install all development tools on your target. • Therefore, cross-compiling toolchains are generally used. They run on your workstation but generate code for your target. Environment

Source code Compilation Cross-compiling machine Native toolchain toolchain

x86

Execution x86 binary ARM binary machine x86 ARM Components

Binutils Kernel headers

C/C++ libraries GCC compiler

GDB debugger (optional) Binutils

• Binutils is a set of tools to generate and manipulate binaries for a given CPU architecture • as, the assembler, that generates binary code from assembler source code • ld, the linker • ar, ranlib, to generate .a archives, used for libraries • objdump, readelf, size, nm, strings, to inspect binaries. Very useful analysis tools ! • strip, to strip useless parts of binaries in order to reduce their size • http://www.gnu.org/software/binutils/ • GPL license Kernel headers (1)

• The C library and compiled programs needs to interact with the kernel Kernel • Available system calls and their numbers • Constant definitions Kernel headers • Data structures, etc. • Therefore, compiling the C library C Library requires kernel headers, and many applications also require them. Applications

• Available in and and a few other directories corresponding to the ones visible in include/ in the kernel sources Kernel headers (2)

• System call numbers, in

#define __NR_exit 1 #define __NR_fork 2 #define __NR_read 3

• Constant definitions, here in , included from , included from #define O_RDWR 00000002 • Data structures, here in struct stat { unsigned long st_dev; unsigned long st_ino; [...] }; Kernel headers (3)

• The kernel-to-userspace ABI is backward compatible • Binaries generated with a toolchain using kernel headers older than the running kernel will work without problem, but won't be able to use the new system calls, data structures, etc. • Binaries generated with a toolchain using kernel headers newer than the running kernel might work on if they don't use the recent features, otherwise they will break • Using the latest kernel headers is not necessary, unless access to the new kernel features is needed • The kernel headers are extracted from the kernel sources using the headers_install kernel Makefile target GCC compiler

• GNU C Compiler, the famous free software compiler • Can compile C, C++, Ada, Fortran, Java, Objective-C, Objective-C++, and generate The image part with code for a large number of CPU relationship ID rId4 was architectures, including ARM, AVR, not found in Blackfin, CRIS, FRV, M32, MIPS, MN10300, the file. PowerPC, SH, v850, i386, x86_64, IA64, Xtensa, etc. • http://gcc.gnu.org/ • Available under the GPL license, libraries under the LGPL. C library

• The C library is an essential component of a Linux system • Interface between the applications and the kernel Kernel • Provides the well-known standard C API to ease application development • Several C libraries are available: C Library glibc, uClibc, eglibc, , , etc. Applications • The choice of the C library must be made at the time of the cross- compiling toolchain generation, as the GCC compiler is compiled against a specific C library. glibc

The image part • http://www.gnu.org/software/libc/ with relationship ID rId4 was not • License: LGPL found in the file. • C library from the GNU project • Designed for performance, standards compliance and portability • Found on all GNU / Linux host systems • Of course, actively maintained • Quite big for small embedded systems: approx 2.5 MB on arm (version 2.9 - libc: 1.5 MB, libm: 750 KB) Using the Toolchain

build host target build host target

Native build Cross build used to build the normal gcc of a used to build a toolchain that runs on workstation your workstation but generates binaries for the target The most common solution in embedded The most common solution in Enterprise Experiment on following

• Gcc c compiler • Ld gnu linker • As assembler • Size info on cs/ds • Nm symbolic info ( var/code commnets/…) • Readelf info on file • Strip remove the debugging info • Objdump disassembly info • Strace system call trace • Objcopy exe/binay copy/conversion • Ar create archive (libraray) • Ranlib indeding of archive • Make automate the build Some supporting utilities can • Ldd info on library for the exe be also tried out • Ldconfig paths edits stat, file, diff, cmp, comm, patch, wc, nl, bc, script, sdiff, vim editor with cscope is a good choice for developers Build Lifecycle of an Image

Source Program Assembly Code Preprocessor Compiler Assembler cpp / gcc -E cc1 / gcc -S as / gcc -c

Object Program

Executables Linker Loader ld / gcc -l Application Build styles

• Dynamic Build • default the process is build with dynamic dependencies. • It means, it uses shared library for the exe to load certain service at load time. Example: $gcc sample.c –o sample.exe $ldd ./sample.exe Linux-gate.so.1 => (0xb7776000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75a9000) /lib/ld-linux.so.2 (0xb7777000)

• Static Build • If the process is build with static build, there is no dynamic dependency. • It means, it uses static library for the exe. • This is fast but occupied a lot of space.static build

• $gcc -static sample.c -o ssample.exe Executable Image on static and dynamic build

App1 App2 AppN App1 App2 AppN

lib1.a lib1.a lib1.a linux-gate.so.1 lib2.a lib2.a lib2.a libc.so.6

ld-linux.so.2 Programmer’s view of Program

Environment variables .stack

.heap

.bss

.data

.rodata

_end .text _edata _etext Executable and Linker Format Maintaining STPs Static library Dynamic library Real name LD_LIBRARY_PATH Production ready with ldconfig So name and versioning techniques Using dynamic linker as an API using libdl.so LD_PRELOAD Do’s and Don’t in Shared Libraries LIBRARIES

• Static libraries • special “archive files” • have extension ’.a’ • created from object files using GNU archiver ‘ar’ • used by linker to resolve references to functions at compile time

• Shared libraries • have extension ’.so’ • preferred over static libraries • Memory optimises • Can be build in two ways • Real name • Soname LIBRARIES

• GNU ar to create a static library: $ gcc -Wall -c -o hello.o hello.c • $ ar cr libhello.a hello.o • The ‘cr’ stands for “create and replace” • The “table of contents” option ‘t’ can list the object files in an existing library • $ ar t libhello.a hello_fn.o bye_fn.o • $ gcc main.c /tmp/tmp/test/libhello.a -o main • $ ./main • Hello, everyone! LIBRARIES

• /* calc.c */ • #include • #include

• int main (void) { • double x = sqrt (2.0); printf ("The square root of 2.0 is %f\n", x); • return 0; • } LIBRARIES

• $ gcc -Wall calc.c -o calc • /tmp/ccbR6Ojm.o: In function ‘main’: • /tmp/ccbR6Ojm.o(.text+0x19): undefined reference to ‘sqrt’ • • ‘/tmp/ccbR60jm.o’ is a temporary object file created for linking • A library should appear after any source files or object files

• $ gcc -Wall calc.c /usr/lib/libm.a -o calc LIBRARIES

• -lNAME will link object files with library file ‘libNAME.a’ in the standard library directories

• $ gcc -Wall calc.c -lm -o calc • If library lglpk uses and depends on lm library, it must appear before lm

• $ gcc -Wall data.c -lglpk -lm • Not all compilers search all libraries, so order libraries from left to right Libraries

•A library is a collection of subprograms used to develop software. •Allows code and data to be reused, shared and changed in a modular fashion. •Linking: A linker resolves the references between executables and libraries. Benefits of Using Libraries

•Software Engineering Perspective: •Increasing the reusability of common routines. •Easy to upgrade by changing the libraries only. •System Utilization Perspective: •The code segment can be sharing at runtime; decrease the consume of memory and disk space. GNU Binary Utilities used with lib

• strings: display all printable characters. • ar: create static-linking libraries. • nm: list symbols from object files. • size: list section sizes and total sizes. • readelf: • objdump: • ldd • ldconfig Print Shared Library Dependencies

• UNIX Platform > ldd /bin/bash linux-gate.so.1 => (0xffffe000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7f1d000) libdl.so.2 => /lib/libdl.so.2 (0xb7f19000) libc.so.6 => /lib/libc.so.6 (0xb7dfb000) /lib/ld-linux.so.2 (0xb7f61000) • Windows Platform • PE Viewer or PE Explorer • PE: Portable Executable Smaller is more efficient

objject object file file static linking function function library library executable files

object object file file dynamic linking pointer pointer shared function library From Source to Execution

Source Program Assembly Preprocessor Compiler Code Assembler cpp / gcc -E cc1 / gcc -S as / gcc -c

dynamic Object static- -linking Program linking

Executables Linker Loader ld / gcc -l Categories of Libraries (by linking time) •Static linking libraries •Dynamic linking libraries •Run-Time Environment libraries •Programming Language libraries Static Linking Libraries

•The code segments will be copy to each executables •Pros: •Easy to use; no dependency problem after compilation. •Cons: •The executable size will be larger. •Require re-linking when libraries changed. Dynamic Linking Libraries (1/2)

• Allow multiple processes to share the same code segment. • Pros: • Greater flexibility • Possible support for plugins. • Cons: • Slow application at start time. • Dependent on the libraries when execution. Dynamic Linking Libraries (2/2)

•The references can be resolved either at: •Load-time •Run-time Location of Libraries

•UNIX Platform •/lib: runtime environment libraries •/usr/lib: for program development Linking with C Runtime Libraries

•Static Linking • gcc –static –o hello-s helloworld.c /usr/lib/libc.a • hello-s: 521,238 bytes •Dynamic Linking • gcc –o hello-d helloworld.c • hello-d: 6,020 bytes •The CRT libraries consume 515,218 bytes. Static-Linking Libraries

•Build •gcc –c mystaticlib.c •ar –r mystaticlib.a mystaticlib.o •Usage •(same as using C runtime libraries) Create the object modules using –fPIC

• $ gcc -fPIC -g -c -Wall mod1.c mod2.c mod3.c • -fPIC (Position Independent Code) causes compiler to generate code that can be loaded anywhere in virtual memory at run-time. • Create the shared library: • $ gcc -shared -o libfoo.so mod1.o mod2.o mod3.o • Usual naming convention: libname.so[.version] • Link program against library : • $ gcc -g -Wall -o prog prog.c libfoo.so • or: • $ gcc -g -Wall -o prog prog.c -L. -lfoo

• This step embeds name of shared library inside executable file. Run?

• But when we try to execute the program:

• $ ./prog • ./prog: error in loading shared libraries: • libfoo.so: cannot open shared object file: • No such file or directory

• The library "libfoo.so" could not be resolved at run-time by the dynamic linker (aka: dynamic linking loader). The Dynamic Linker

• Examines shared library dependencies in executable file and • Loads shared libraries into memory (if they are not already); • It is itself a shared library which is part of every ELF executable using shared libraries: /lib/ld-linux.so • It applies a set of rules to find libraries referenced by the program. • The rules specify a set of standard directories. • (For example, many shared libraries reside in /lib and /usr/lib.) • The error message earlier occurred because our library is in the current directory, which is not part of standard list LD_LIBRARY_PATH

• We need to give the dynamic linker information on how to find our shared library at run-time • One solution: LD_LIBRARY_PATH. • Set this environment variable to a list of colon-separated directories. • Dynamic linker searches these directories before looking in standard library directories. • $ LD_LIBRARY_PATH=. ./prog • Called mod1-x1 • Called mod2-x2

• Note: production applications should not use LD_LIBRARY_PATH as • Users should not have to know where the library is located The shared library soname

• In the earlier example, we embedded the actual name (the real name) of the shared library in an executable file. • It is possible to create an alias, called the soname, which will be embedded in an executable file instead of the real name. • At run-time, the dynamic linker will use the soname when searching for the library. • The purpose of the soname is to provide a level of indirection. • At run-time, executable can use a version of the shared library that is different (but compatible) from that against which it was linked. how to use a soname

• Specify soname when creating shared library: • $ gcc -fPIC -c -Wall -g mod1.c mod2.c mod3.c • $ gcc -shared -Wl,-soname,libbar.so -o libfoo.so \ • mod1.o mod2.o mod3.o • -Wl,-soname,libbar.so instructs linker to mark the shared library libfoo.so with the soname libbar.so.

• Create executable: • $ gcc -g -Wall -o prog prog.c libfoo.so

• Linker detects that libfoo.so contains the soname libbar.so and embeds the latter name inside the executable. Run the program

• $ LD_LIBRARY_PATH=. ./prog • ./prog: error in loading shared libraries: • libbar.so: cannot open shared object file: • No such file or directory • Dynamic linker cannot find anything named libbar.so. • Create a symbolic link from the soname to the real name of the library:

• $ ln -s libfoo.so libbar.so • $ LD_LIBRARY_PATH=. ./prog • Called mod1-x1 • Called mod2-x2

• At run-time this link can point to a version of the library which is different from the version against which linking was performed. Shared library versions and naming

• If a new version of a shared library is compatible with an existing library, we can make a new minor version of the library.

• If a new version of a shared library is incompatible with an existing library, we must make a new major version of the library.

• Constraint: it must be possible to continue running programs requiring the older version of the library.

• Solution: a naming convention is used for shared library real names and sonames. Real name REAL NAME is Name of the file containing library code. Format: libname.so.major-id.minor-id

• Major version identifier is a number which is sequentially incremented with each incompatible release of the library.

• Minor version identifier distinguishes different compatible minor versions of a library within the same major version.

• Usually either a number, or two numbers separated by a dot, with first number identifying minor version, and second number indicating a patch level or revision number within the minor version.

Examples: • libdemo.so.1.0.1 • libdemo.so.1.0.2 • libdemo.so.2.0.1 • libreadline.so.4.0 Soname Format: libname.so.major-id • soname includes the same major version identifier as corresponding real name, but does not include minor version identifier.

Purpose: run-time loading is dependent only on major version number of the library • soname is created as a symbolic link (usually in same directory as real name). • The soname for each major library version points to most recent minor version. • Since it is the soname (not the real name) that is embedded in executable by linker: At any time, we can change soname symbolic link to point to a newer minor version. • Different major versions can co-exist and be accessed by the programs that require them. Examples of sonames (along with the real names to which they might be symbolically linked): • libdemo.so.1 -> libdemo.so.1.0.2 • libdemo.so.2 -> libdemo.so.2.0.1 • libreadline.so.4 -> libreadline.so.4.0 Linker name

Linker name Format: libname.so

Purpose: allows us to construct version-independent link commands which automatically operate with the right (i.e. most up to date) version of the shared library.

Created as a symbolic link to either real name or soname of most recent major version of the library.

More convenient to have it point to soname.

Examples: libdemo.so -> libdemo.so.2 Libreadline.so -> libreadline.so.4 create a shared library using standard naming conventions

Create the shared library with real name libdemo.so.1.0.1 and soname libdemo.so.1. $ gcc -fPIC -g -c -Wall mod1.c mod2.c mod3.c $ gcc -shared -Wl,-soname,libdemo.so.1 -o libdemo.so.1.0.1 \ mod1.o mod2.o mod3.o Create symbolic links for the soname and linker name: $ ln -s libdemo.so.1.0.1 libdemo.so.1 $ ln -s libdemo.so.1 libdemo.so $ ls -l libdemo.so* | cut -c 1-11,55- # Verify the setup lrwxrwxrwx libdemo.so -> libdemo.so.1 lrwxrwxrwx libdemo.so.1 -> libdemo.so.1.0.1 -rwxr-xr-x libdemo.so.1.0.1 Build executable using the linker name: $ gcc -g -Wall -o ./prog prog.c -L. -ldemo Run the program as usual: $ LD_LIBRARY_PATH=. ./prog Called mod1-x1 Called mod2-x2 Dynamic loading with Linux

Function Description dlopen Makes an object file accessible to a program dlsym Obtains the address of a symbol within a dlopened object file dlerror Returns a string error of the last error that occurred dlclose Closes an object file Description

#include void *dlopen( const char *file, int mode ); With a handle to the ELF object, you can identify addresses to symbols within this object using the dlsym call. This function takes a symbol name, such as the name of a function contained within the object. The return value is a resolved address to the symbol within the object: void *dlsym( void *restrict handle, const char *restrict name ); If an error occurs during a call with this API, you can use the dlerror function to return a human-readable string representing the error. This function has no arguments and returns a string if a prior error occurred or returns NULL if no error occurred: char *dlerror(); Finally, when no additional calls to the shared object are necessary, the application can call dlclose to inform the operating system that the handle and object references are no longer necessary. This is properly reference-counted, so that multiple users of a shared object do not conflict with one another (it remains in memory as long as there is a user for it). Any symbols resolved through dlsym for the closed object will no longer be available. char *dlclose( void *handle ); Dynamically Loaded (DL) Libraries

• Dynamically loaded (DL) libraries are libraries that are loaded at times other than during the startup of a program.

• They're particularly useful for implementing plugins or modules, because they permit waiting to load the plugin until it's needed. • For example, the Pluggable Authentication Modules (PAM) system uses DL libraries to permit administrators to configure and reconfigure authentication. Using readelf for info

$ldd $readelf -ldl

Elf file type is (Executable file) Entry point 0x8048618 There are 7 program headers, starting at offset 52

Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4 INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x00958 0x00958 R E 0x1000 LOAD 0x000958 0x08049958 0x08049958 0x00120 0x00128 RW 0x1000 DYNAMIC 0x00096c 0x0804996c 0x0804996c 0x000d0 0x000d0 RW 0x4 NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

$ Testing Embedded Application QEMU Cross Applications Qemu

Great tool for embedded developers What is

• Quick EMUlator” is a processor emulator that relies on dynamic binary translation to achieve a reasonable speed while being easy to port to new host CPU architectures • When used as a machine emulator, QEMU can run OSes and programs made for one machine • EX: ARM board on a different machine (e.g. your own PC). • By using dynamic translation, it achieves very good performance. • When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. • When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests. Typical Setup

Requirement/ Board specific configuration Configure, build & test your kernel Configure, build, & test file system Build & test bare apps 3

Get QEMU Get tool chain Configure QEMU for KVM Configure tool chain Build & Install Build & Install Test the QEMU Test tool chain 1 2 Test Application on emulator

• arm-none-linux-gnueabi-gcc sample.c –o sample.arm

• Qemu-arm –L /path_to_cross_sdk/arm…/libc/lib sample.arm