Gilad Ben-Yossef August 4th, 2008
A new video post tutorial, showing how to locate the function where your Linux application crashed if all you know is the address where the crash happened using two common Linux utilities: ldd and nm.
Enjoy!
Gilad Ben-Yossef July 8th, 2008
One of the tasks embedded system developers face is managing boot latency, or the time it takes for a device to become functional after power up.
After all, a set top box that will take more then 60 seconds from the time the “On” button is pressed until the end customer can at least interact with the menus, for example, will most likely be returned to the store for a refund, no matter what feature set it has. When it come to our gadgets, we are all hungry for immediate satisfaction, it seems.
There are many tricks one can employ to to achieve boot time nirvana, but as Knuth taught us, premature optimization is the root of all evil. Therefore, before we turn our efforts to optimize boot latency, we should first try to measure what that boot latency really is and what part of the boot sequence contribute to it, lest we optimize the wrong thing.
Generally speaking, on a x86 (32bit or 64 bit), the boot process of a Linux system is comprised of the following phases and milestones:
Unfortunately, measuring the contribution of each of these phases to the overall boot latency is not an easy task to accomplish. At each of the phases different kind of code is executing on the machine: from the 16 bit BIOS code which is part of the machine firmware, via the 16 or 32 bit boot loader code, the 32 bit kernel code and the finally user applications - each of these is executing in a completely different software environment from the other and it is hard to find a common ground to compare the time each phase takes.
Luckily, the x86 architecture provides a useful tool: the TSC (or Time Stamp Clock) register. The TSC register was introduced in the original Intel Pentium CPU and counts the number of clock ticks from the last processor reset. Reading the current value of the TSC register is done using the RDTSC instruction.
Assuming no processor frequency changes (for example via SpeedStep technology) takes place and that we always sample the register of the same core in a multi core environment, both of which are easy to guarantee during the boot phase, the TSC register provides us with an accurate hi-res timer through which we can benchmarks the various phases in the boot process.
Tuxology team June 30th, 2008
We’ve just added a brand new tutorial to the lectures section on the site, entitled: “Crash and burn: Writing Linux application fault handlers“. Check out the full description, slides and example code on the lecture page.
Or, if you’d rather see our very own Gilad Ben-Yossef present the tutorial in front of a live audience, you’re welcome to attend one of the following venues:
Hope to see you there!
Tuxology team
Tuxology team June 5th, 2008
Eclipse is an open source development platform comprised of extensible frameworks, tools and run times for building, deploying and managing software across the life cycle.
CDT is the name of the C/C++ development plug-in. It includes a graphical GDB front end.
The following slides are a short visual “how to” demonstrating configuring and using CDT to debug a remote target with GDB.
Gilad Ben-Yossef May 15th, 2008
Today we have a special reader request from an anonymous reader (slightly edited):
Hello,
Can you help me with some link issue which I face?
I need to compile tree of c-sources which produce .so files and exe
files. I want to decrease the sizes of .so by throwing away unused symbols.
I can compile my tree statically and used as compiler flags –static -ffunction-sections -fdata-sections and link with –gc-sections option and it reduces all the unneeded symbols but I want to achieve the same effect in dynamic linking.
Do you know some efficient way to do it?
Thanks,
Anonymous Reader
So the question is: how to make a minimal set of dynamic libraries for a known set of executables that only contain the code for those symbols which the executables actually use, thus saving expensive storage?
The quite simple answer is that there exists a Python utility that does exactly what you want called mklibs - It produces cut-down shared libraries that contain only the routines required by a particular set of executables.
On Debian just go “sudo apt-get install mklibs”, or you can get the source straight from the Buildroot source repository here.
If you don’t like Python (you really should!) you can try an older, shell script based variation on the same theme found here.
Note that you can pass the cross compiler prefix with the “–target” option, which is of course needed for supporting cross compilation.
Hope you found it useful and if you have more questions about Linux development you’d like answered, just let us know.
This post originally appeared in the Codefidence Technoblog
Gilad Ben-Yossef May 15th, 2008
Shared libraries, sometime also referred to as DSO (for Dynamic Shared Objects) or DLL (for Dynamically Loadable Modules), offer an easy way to pack together useful functions and data as a code library that can be easily reused, updated separately from all the application making use of it and most important - under certain conditions allows most the code and data of the library to only be loaded once to the machine RAM regardless of the number of applications using it.
A shared library is thus normally comprised of a set of global functions which may be called by applications (or other libraries) that link with the library.
Given the shared nature of shared libraries, it is often useful to provide a constructor for the code library which will run each time the library is loaded by an application. Doing this is very simple, using the GNU specific constructor attribute.
Here is a code example:
/* init_demo.c */ #include <unistd.h> #include <stdlib.h> #include <string.h> static void __attribute__ ((constructor)) \ lib_init(void); static void lib_init(void) { printf("Library ready. \n"); return; }
Then build the the shared library using the following GNU Makefile:
.PHONY: clean libinitdemo.so.1.0.0: init_demo.c $(CC) -fPIC init_demo.c -shared \ -Wl,-soname,libinitdemo.so.1 -o \ libinitdemo.so.1.0.0 clean: $(RM) -f libinitdemo.so.1.0.0
TIP
Combining a shared library constructor as shown above with use of LD_PRELOAD can be a powerful way to add construction code to existing programs without changing their source code and indeed, without requiring access to their source code at all.
This post originally appeared in the Codefidence Technoblog
Gilad Ben-Yossef May 15th, 2008
It can sometime be very useful to force an application to force to use a specific network interface for routing traffic, the regular routing tables not withstanding.
An example for such cases is where an embedded Linux system has a management network interface and a separate regular network interface where regular traffic should go:
So long as the two interfaces use two different IP addresses from non overlapping network it is very easy - simply bind the management application socket to the management IP and let the routing table do the rest.
What to do, however, if product definition calls for supporting two different and separate, default gateway settings for management and media traffic? Although we can assign multiple default gateway routing table entries, how to make sure the management applications use one and all other traffic use another?
This is where the SO_BINDTODEVICE socket option comes to our rescue. We will install two default gateway entries: a normal one for the media traffic and another one for the management traffic, for which we will define a high metric so it will normally will not be used.
Then, we will set the SO_BINDTODEVICE socket option on sockets opened in management application, thus forcing the Linux networking stack to disregard any routing table entries not going through the specific device, but only for those specific sockets.
It looks something like this:
#include <sys/socket.h> #include <net/if.h> struct ifreq interface; struct socket sock; /* Management net interface name */ #define IFNAME "eth3" /* Acquire socket here ... */ strncpy(interface.ifr_ifrn.ifrn_name, IFNAME, \ IFNAMSIZ); if (setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, \ (char *)&interface, sizeof(interface)) < 0) { perror("SO_BINDTODEVICE failed"); /* Deal with error... */ }
But wait! this is all well and good when we have the management application source code. This however is not always the case. Fear not! this too can be dealt with by hijacking the socket library call:
#include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <net/if.h> #define __USE_GNU // Get RTLD_NEXT definition #include <dlfcn.h> /* Management interface */ #define IFNAME "eth3" int socket(int domain, int type, int protocol) { int (*origsock)(int domain, int type, int protocol); char * error; int sock; origsock = dlsym(RTLD_NEXT, "socket"); if ((error = dlerror()) != NULL) { fprintf (stderr, "%s\n", error); exit(1); } sock = origsock(domain, type, protocol); if(sock != -1) { struct ifreq interface; strncpy(interface.ifr_ifrn.ifrn_name, IFNAME, \ IFNAMSIZ); if (setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, \ (char *)&interface, sizeof(interface)) < 0) { perror("sendpacket: setting SO_BINDTODEVICE"); exit(1); } } return sock; }
Compile this small library with (or create a proper Makefile)
$ gcc sendto.c -fPIC -o sendto.so -ldl -shared
To use:
LD_PRELOAD=sendto.so ./management_app
This post originally appeared in the Codefidence Technoblog
Tuxology team May 15th, 2008
Slides for the presentation on the Linux dynamic linker given by Gilad Ben-Yossef, Codefidence CTO, at the Wind River Embedded Linux Conference in Ramat Ilan, Israel in December 4, 2007 has been published on the Codefidence web site.
Gilad Ben-Yossef May 15th, 2008
Linux kernel 2.6 and latest versions of 2.4 support two system calls that allow one to limit processes to specific CPUs.
The system calls are:
#include <sched.h> int sched_setaffinity(pid_t pid, unsigned int len, unsigned long *mask); int sched_getaffinity(pid_t pid, unsigned int len, unsigned long *mask);
pid is the process id of the process to assign to certain CPUs. Use ‘0′ here to denote the current process.
len is the length of the CPU bit mask, and mask is a pointer to a bit mask denoting which CPU can the process run on.
For a good discussion and a code example, look here:
http://www-128.ibm.com/developerworks/linux/library/l-affinity.html
This post originally appeared in the Codefidence Technoblog
Gilad Ben-Yossef May 15th, 2008
A lot of POSIX API’s require a PID, or process ID, as a parameter. Sometime it is useful to use such an API on a thread, rather then a process.
Since Linux internally implements all processes and threads as tasks, one can use the Linux specific gettid(2) system call to get the “Thread ID” of a thread, which is really equal to a process PID, at least so much as to be useful as a parameter for a POSIX system call that requires a PID.
The use is Linux specific, non portable and it is not clear if it is a stable API or an undocumented coincidence. Use with care.
This post originally appeared in the Codefidence Technoblog