Lecture 10: Processes II-B

1. Lecture 10: Processes II-B • Static vs Dynamic Loading • Files: .a, .o, and .so • Files: .lib and .dll • Library Calls • System Calls

2. Programs • We already know that programs… • …are static files on the hard drive • …are in EXE, COM, and ELF formats • …become processes via ‘exec’ call • What else is there to know?

3. Programs • We already know that programs… • …are static files on the hard drive • …are in EXE, COM, and ELF formats • …become processes via ‘exec’ call • What else is there to know? • Lots!

4. Files: .a, .o, and .so • These are often confusing • You’ll see them all in your career • Let’s take a good look at them

5. Files: .a, .o, and .so • These are often confusing • You’ll see them all in your career • Let’s take a good look at them… • …shortly! • First let’s review how a program is built!

6. Building A Program • 2-pass approach • 1st pass • Compile • Create list of available symbols and required symbols • 2nd pass • Link • Make sure we have all required symbols • (…and then use them to build our program)

7. .o Files • This is “myFile1.cpp” • Let’s compile this  “myFile1.o” • gcc -c myFile1.cpp -o myFile1.o • This is machine code • Contains code/data for functions/variables defined in myFile1.cpp

8. .o Files • ‘nm’ command will show us “the contents” • Reads the binary • Extracts stuff we care about • nm myFile1.o

9. .o Files

10. .o Files • So, .o files are… • …source code • …that has been binary-ized • …and made available to be placed into something larger (library or program) • Building a program is trivial • Let’s build us a library! \m/ >.< \m/

11. .o Files • Each .o file contains a portion of our overall library • I could easily link every .o file • Why would I want to avoid this? • It’s tedious • It’s prone to user errors • It’s easy to avoid

12. .a Files • Highly preferable to collect .o files into a group • Let’s take two files: myFile1.cpp myFile2.cpp

13. .a Files • Let’s make our .o files • gcc -c myFile1.cpp myFile2.cpp • Now transform into an archive • arcrmyLib.a myFile1.o myFile2.o • So what do the contents of myLib.a look like? • nm myLib.a

14. .a Files

15. .a Files • So, .a files are just a collection of .o files concatenated • This can obviously make a library very large • This is referred to as a static library

16. .so Files • I may not want to have the entire library loaded up • Let’s make a shared object or dynamic library

17. .so Files • Let’s (re)make our object file • gcc -c -fPIC myFile1.cpp • -fPIC: Make position-independent code • Now let’s make a shared object • gcc –shared myFile1.o -o myLib.so • -shared: make this a shared object • -o: override default output file name • So what’s it look like? • nm myLib.so

18. .so Files

19. .so Files

20. Files: .lib and .dll • .lib == .a, except… • …there are .lib files that are “import” libraries; essentially, a blueprint for DLL • .lib files tie you to a specific compiler/linker • .dll == .so • DLLs are a little funny in Windows • Just keep in mind we’re hand-waving the funny stuff

21. Included Libraries • We saw how our code became a library • Let’s start at the other end (the program) and see what libraries are within it. • ldd <myProgram.bin>

22. Included Libraries • OpenCV • GTK  • Cairo  • XML 

23. Library Calls • A program almost always relies on other libraries • How can we tell what library calls are being made?

24. Library Calls • A program almost always relies on other libraries • How can we tell what library calls are being made? ltrace! • E.g.: ltracepwd

25. ltrace

26. System Calls • A program may or may not use a library • So may or may not have library calls • A program WILL have system calls • How can we tell what system calls are being made?

27. System Calls • A program may or may not use a library • So may or may not have library calls • A program WILL have system calls • How can we tell what system calls are being made? strace! • E.g.:stracepwd

28. strace