Operating Systems 2021F: Tutorial 2 - Revision history

Soma: /* A: Function calls, library calls, and system calls */

2021-09-23T02:18:02Z

A: Function calls, library calls, and system calls

← Older revision		Revision as of 02:18, 23 September 2021
Line 53:		Line 53:
	# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''		# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
	# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls?		# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls?
			# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
	# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?		# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?
	# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.		# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

Soma: /* Tasks */

2021-09-22T18:53:17Z

Tasks

← Older revision		Revision as of 18:53, 22 September 2021
Line 40:		Line 40:
	==Tasks==		==Tasks==

	===Function calls, library calls, and system calls===		===A: Function calls, library calls, and system calls===

	For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (<b>substituting the appropriate source file for prog.c</b>). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".		For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (<b>substituting the appropriate source file for prog.c</b>). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".
Line 56:		Line 56:
	# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.		# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

	===Comparing C and assembly===		===B: Comparing C and assembly===

	Do the following with hello.c and syscall-hello.c, as before.		Do the following with hello.c and syscall-hello.c, as before.
Line 79:		Line 79:
	# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?		# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

	===Examining the runtime memory map===		===C: Examining the runtime memory map===

	Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.		Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.

Soma: /* Function calls, library calls, and system calls */

2021-09-22T18:46:01Z

Function calls, library calls, and system calls

← Older revision		Revision as of 18:46, 22 September 2021
Line 52:		Line 52:
	# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?		# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
	# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''		# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
	# See what library calls prog-static produces by running <tt>ltrace -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? ~~(If ltrace isn't installed, run <tt>sudo apt-get install ltrace</tt>)~~		# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls?
	# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?		# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?
	# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.		# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

Soma at 13:58, 20 September 2021

2021-09-20T13:58:13Z

← Older revision		Revision as of 13:58, 20 September 2021
Line 1:		Line 1:
	In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out. If you haven't already, please set up and use a VM on openstack for this work.

	If you ~~haven't already~~, ~~please set up and use~~ a ~~VM on openstack for~~ this ~~work~~.		If you turn in written answers, submit them as a single text file named "<username>-comp3000-t2.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Tutorial 2", your name, student number, and the date of submission.

	==Background==		==Background==

Soma: /* Background */

2021-09-20T13:48:53Z

Background

← Older revision		Revision as of 13:48, 20 September 2021
Line 7:		Line 7:
	A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.		A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

	Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for code that is loaded into a process ~~at runtime~~, while system calls allow for code in other processes or the OS kernel to be accessed.		Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

	===Assembly Language===		===Assembly Language===

Soma at 13:47, 20 September 2021

2021-09-20T13:47:55Z

← Older revision		Revision as of 13:47, 20 September 2021
Line 1:		Line 1:
	~~'''This tutorial is still in development.'''~~

	In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

Soma: /* Static & Dynamic Libraries */

2021-09-20T13:47:11Z

Static & Dynamic Libraries

← Older revision		Revision as of 13:47, 20 September 2021
Line 24:		Line 24:

	Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:		Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
	* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)		* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
	* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.		* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
	Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.		Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

Soma: /* Background */

2021-09-20T13:46:50Z

Background

← Older revision		Revision as of 13:46, 20 September 2021
Line 9:		Line 9:
	A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.		A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

	Here we're going to talk about ~~dynamic~~ libraries and system calls, two ways programs gain access to additional functionality. ~~Dynamic libraries~~ are for code that is loaded into a process at runtime, while system calls allow for code in other processes or the OS kernel to be accessed.		Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for code that is loaded into a process at runtime, while system calls allow for code in other processes or the OS kernel to be accessed.

	===Assembly Language===		===Assembly Language===

Soma: /* Background */

2021-09-20T13:46:25Z

Background

← Older revision		Revision as of 13:46, 20 September 2021
Line 11:		Line 11:
	Here we're going to talk about dynamic libraries and system calls, two ways programs gain access to additional functionality. Dynamic libraries are for code that is loaded into a process at runtime, while system calls allow for code in other processes or the OS kernel to be accessed.		Here we're going to talk about dynamic libraries and system calls, two ways programs gain access to additional functionality. Dynamic libraries are for code that is loaded into a process at runtime, while system calls allow for code in other processes or the OS kernel to be accessed.

	===~~Dynamic Libraries~~===		===Assembly Language===

	~~Most applications on the system do not contain all the~~ code ~~that they need right within the executable. Instead~~, ~~dynamic libraries are loaded into the program address space when the program loads~~. ~~As an example, the standard C library, which contains such functions as <tt>printf</tt>, is loaded in~~ at ~~run-time. Typically dynamic libraries are stored in /lib or /usr/lib~~.		When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

	~~The dynamic libraries associated with~~ a ~~program~~ binary ~~can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked~~.		* Compile C code into assembly code (.s files).
			* Assemble assembly code into machine code placed in object code files (.o files).
			* Link object code files together to create a runnable binary.

	Note that code in dynamic libraries runs inside of the process loading the code; thus, ~~dynamic~~ library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).		If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

			===Static & Dynamic Libraries===

			Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
			* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
			* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
			Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

			The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

			Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

	===System Calls===		===System Calls===

Soma: /* 3000memview.c */

2021-09-20T13:33:18Z

3000memview.c

← Older revision		Revision as of 13:33, 20 September 2021
Line 108:		Line 108:
	</syntaxhighlight>		</syntaxhighlight>

	===3000memview.c===		===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
	<syntaxhighlight lang="c" line>		<syntaxhighlight lang="c" line>
	#include <stdio.h>		#include <stdio.h>