Laboratory: Who’s linked to what?
As usual, keep a log in the file lab.txt of what you do in the lab so that you can reproduce the results later. This should not merely be a transcript of what you typed: it should be more like a true lab notebook, in which you briefly note down what you did and what happened.
For this laboratory, you will find out about which programs are linked to which libraries.
#. Use the ldd command to see which dynamic libraries your trivial program uses.
$. Use the strace command to see which system calls your trivial program makes. Which of these calls are related to dynamic linking and what is the relationship?
&. Invoke ldd on each command in your list. If there are error messages, investigate why they’re occurring.
Homework: Split an application into dynamically linked modules
In this homework you will divide a small example application into dynamically linked modules and a main program, so that the resulting executable does not need to load code that it doesn’t need. Although this is just a toy example which would probably not be worth optimizing in this way, in real life many applications use dynamic linking to improve performance in common cases, and the skills used
in this small exercise can be helpful in larger programs.
The skeleton tarball contains the following:
A file randall.c that is a single main program, which you are going to split apart.
A Makefile that builds the program randall.
First, read and understand the code in randall.c. Do not modify it, or any of the other files in the skeleton tarball.
Second, split the randall implementation by copying its source code into the following modules, which you will need to modify to get everything to work:
$. randlibsw.c should contain the software implementation of the random number generator. Like randlibhw.c, it should start by including randlib.h and should implement the interface described by randlib.h. Since the software implementation needs initialization and finalization, this implementation should also define an initializer and a finalizer function, using GCC’s “__attribute__ ((constructor))” and “__attribute__ ((destructor))” declaration specifiers.
randmain.c should contain the main program that glues together everything else. It should includerandcpuid.h (as the corresponding module should be linked statically) but not randlib.h (as the corresponding module should be linked after main starts up). Depending on whether randcpuid reports that the hardware supports the RDRAND instruction, this main program should dynamically link the hardware-oriented or software-oriented implementation of randlib, doing the dynamic linking via dlopen and dlsym. Also, the main program should call dlclose to clean up before exiting. Like randall, if any function called by the main program fails, the main program should report an error and exit with nonzero status.
Each module should include the minimal number of include files; for example, since randcpuid.c doesn’t need to do I/O, it shouldn’t include stdio.h. Also, each module should keep as many symbols private as it can; for example,
since randcpuid does not need to export the cpuid function, that function should be static and not extern.
Next, write a makefile include file randmain.mk that builds the
program randmain using three types of linking. First, it should use static linking to combine randmain.o and randcpuid.o into a single program executable randmain. Second, it should use dynamic linking as usual to link the C library and any other necessary system-supplied files before its main function is called. Third, after main is called, it should use dynamic linking via dlsym as described
above. randmain.mk should link randmain with the options “-ldl -Wl,-
rpath=$PWD”. It should compile randlibhw.c and randlibsw.c with the -fPIC options
as well as the other GCC options already used. And it should build shared object
files randlibhw.so and randlibsw.so by linking the corresponding object modules
with the -shared option, e.g., “gcc … -shared randlibsw.o -o randlibsw.so”.
The supplied Makefile includes randmain.mk, so you should be able to type
just make to build all four files: randall, randmain, randlibhw.so, and randlibsw.so. If randmain needs to generate any random numbers, it loads
either randlibhw.so or randlibsw.so (but not both) to do its work. You can verify this by using “strace ./randmain” or by using a debugger.
Submit the file dlsubmission.tgz, which you can build by running the command make submission.
All files should be ASCII text files, with no carriage returns, and with no more than 132 columns per line. The shell command
expand lab.txt randmain.mk \
randcpuid.c randlibhw.c randlibsw.c randmain.c | awk ‘/\r/ || 200 < length’
should output nothing.
© 2015–2016 Paul Eggert. See copying rules.
$Id: assign8.html,v 1.38 2016/11/08 22G00G38 eggert Exp $