Advanced - Libraries Fall 2026

• Submission Instructions
  • Presentation/Checkoff
• Preface
• Runtime library linking (10)

Submission Instructions

This homework will be submitted as a repository on the EECS GitLab server. The repository you submit will be a private Project with the name/path eecs201-adv-lib with akamil added as a Reporter. The branch plugin will be the one that is checked.

To finish the submission process and get your submission score, you will need to run the autograder. You will need to SSH into the course server (see Basic - Intro):

local$ ssh uniqname@peritia.eecs.umich.edu

(the local$ referring to a shell prompt on your system)

and then run eecs201-test:

peritia$ eecs201-test adv-lib

(the peritia$ referring to a shell prompt on the server)

Presentation/Checkoff

In addition to submitting this assignment, you will need to attend a lab session after the deadline to discuss your work with the course staff. Refer to the course schedule for the window for doing so for this assignment.

As part of the discussion, be prepared to do the following:

• Explain your approach for the assignment. What documentation did you read, and how did you find it? What did you try that didn’t work, and what was your process for figuring out how to fix it?

• Summarize what you learned from the assignment.

• Discuss how you plan on implementing the tools in this assignment and what you learned in your future projects.

• Apply your approach for solving the problems in this assignment to a new problem that you have not seen before.

I suggest keeping these in mind while doing the assignment, and writing down your thoughts so that you can review them before the checkoff.

Your overall score for the assignment will be a combination of your submission score and the presentation/checkoff score. Refer to the syllabus for the details.

Preface

In this assignment you’ll be provided yet another zipped archive containing some starter files.

https://www.eecs.umich.edu/courses/eecs201/fa2026/files/assignments/adv-lib.tar.gz

Runtime library linking (10)

A closely related topic to the idea of dynamic/shared libraries is the idea of dynamic linking at runtime.

Normally when you run a program, the dynamic libraries that it is linked against would be loaded at program load time.

While doing it at load time is more dynamic than say, static linking, you can be even more dynamic by loading libraries at runtime!

On POSIX systems we have the dl library that provides the ability to run the dynamic linker to load libraries at runtime (on Windows there’s a similar function called LoadLibrary).

With the ability to load code at runtime, we can implement the idea of plugins! In this assignment, we’ll be filling out the framework for a plugin system.

Files are provided in the extracted archive. How this is structured is that runner.c is compiled into runner and serves as the “driver” program that loads plugins. Plugins are merely dynamic shared objects: *.so files.

There’s a Makefile target that turns plugin*.c files into plugin*.so files. The plugins for this application follow a standard where they must implement three functions: plugin_init(), plugin_run(), and plugin_cleanup(). They also must have two strings for identification: plugin_name and plugin_version.

Your job is to utilize dlopen, dlsym, and dlclose (they have manpages!), as well as a bit of function pointers, to implement the TODOs in the runner.c code.

If you have not taken EECS 370, you may be unaware of what a “symbol” is. A “symbol” is an identifier for some resource, such as a global variable or a function. In the context of binary executables and libraries, these symbols are associated with an address in memory where the resource is. For instance, the symbol "plugin_init" for one of the plugins may resolve to address 0x4100 and the symbol "plugin_cleanup" may resolve to 0x4200. By getting symbols from a library you’re effectively locating where the resource is so you can use it (via the magic of pointers!).

Helpful hints:

• Note that dlsym() returns a pointer to your queried resource. Think about how that interacts with resources that are themselves pointers like const char *. For example, a resource that is an int will have a pointer to it returned (an int *). What happens if the resource is a const char *? Playing with pointers is half the fun of C and C++ ;)

Steps:

1. Initialize a Git repository in the extracted adv-lib directory with an initial branch of plugin. If your Git version does not support this, create the plugin branch after you make your first commit.

2. Create a private project named eecs201-adv-lib on the EECS GitLab (gitlab.eecs.umich.edu) add the instructor akamil as a Reporter. Set this EECS GitLab project as your remote: you’ll be pushing to it in order to submit.

3. Modify runner.c and implement the required behavior.

4. Fill out the report.txt file in the following steps:

5. On the first line provide an integer time in minutes of how long it took for you to complete this assignment. It should just be an integer: no letters or words.

6. On the second line and beyond, write down what you learned while doing this assignment. If you already knew how to do all of this, put down “N/A”.

7. Commit your report.txt file and push your commits to your remote.

8. Run the autograder!