At first glance, both the executables that a compiler produces, and the libraries that are used during the building process seem like they’re not very accessible. They are these black boxes that make an application go, or make the linker happy when you hand it the ‘right’ library file. There is also a lot to be said for not digging too deeply into either, as normally things will Just Work™ without having to bother with such additional details.
The thing is that both executables and libraries contain a lot of information that normally is just used by the OS, toolchain, debuggers and similar tools. Whether these files are in Windows PE format, old-school Linux
a.out or modern-day
.elf, when things go south during development, sometimes one has to break out the right tools to inspect them in order to make sense of what is happening.
This article will focus primarily on the Linux platform, though most of it also applies to BSD and MacOS, and to some extent Windows.
Continue reading “Peeking Inside Executables And Libraries To Make Debugging Easier”
One of the nice things about Linux and similar operating systems is that you can investigate something to any level you wish. If a program has a problem you can decompile it, debug it, trace it, and — if necessary — even dig into the source code for the kernel and most of the libraries the program is probably using. However, the tools to do this aren’t ones you use every day. One very interesting tool is
strace. Using it you can see what system calls any program makes and that can sometimes give you important clues about how the program works or, probably more often, why it doesn’t work.
Let’s consider the least complex use of the command. Suppose you want to make symlink from
testxmit.grc to the
/tmp directory. That command is simple:
ln -sf testxmit.grc /tmp
But if you tell
strace to run it, the command becomes:
strace ln -sf testxmit.grc /tmp
You might want to redirect the output to a file using the shell or the
-o option, though. Some commands generate a lot and often the first page or two of output isn’t really what you care about anyway. Continue reading “Linux Fu: Tracing System Calls”